Export limit exceeded: 34857 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (34857 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-21986 | 1 Oracle | 1 Vm Virtualbox | 2026-01-29 | 7.1 High |
| Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are 7.1.14 and 7.2.4. Easily exploitable vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle VM VirtualBox. Note: This vulnerability applies to Windows VMs only. CVSS 3.1 Base Score 7.1 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H). | ||||
| CVE-2025-47912 | 1 Golang | 2 Go, Net | 2026-01-29 | 5.3 Medium |
| The Parse function permits values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: "http://[::1]/". IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement. | ||||
| CVE-2025-9914 | 1 Sick | 4 Baggage Analytics, Logistic Diagnostic Analytics, Package Analytics and 1 more | 2026-01-29 | 4.3 Medium |
| The credentials of the users stored in the system's local database can be used for the log in, making it possible for an attacker to gain unauthorized access. This could potentially affect the confidentiality of the application. | ||||
| CVE-2023-21479 | 2 Google, Samsung | 6 Android, Android, Mobile and 3 more | 2026-01-28 | 5.3 Medium |
| Improper authorization in Smart suggestions prior to SMR Apr-2023 Release 1 in Android 13 and 4.1.01.0 in Android 12 allows remote attackers to register a schedule. | ||||
| CVE-2026-24420 | 2 Phpmyfaq, Thorsten | 2 Phpmyfaq, Phpmyfaq | 2026-01-28 | 6.5 Medium |
| phpMyFAQ is an open source FAQ web application. Versions 4.0.16 and below allow an authenticated user without the dlattachment permission to download FAQ attachments due to a incomprehensive permissions check. The presence of a right key is improperly validated as proof of authorization in attachment.php. Additionally, the group and user permission logic contains a flawed conditional expression that may allow unauthorized access. This issue has been fixed in version | ||||
| CVE-2026-24422 | 2 Phpmyfaq, Thorsten | 2 Phpmyfaq, Phpmyfaq | 2026-01-28 | 5.3 Medium |
| phpMyFAQ is an open source FAQ web application. In versions 4.0.16 and below, multiple public API endpoints improperly expose sensitive user information due to insufficient access controls. The OpenQuestionController::list() endpoint calls Question::getAll() with showAll=true by default, returning records marked as non-public (isVisible=false) along with user email addresses, with similar exposures present in comment, news, and FAQ APIs. This information disclosure vulnerability could enable attackers to harvest email addresses for phishing campaigns or access content that was explicitly marked as private. This issue has been fixed in version 4.0.17. | ||||
| CVE-2025-29448 | 1 Easyappointments | 1 Easy\!appointments | 2026-01-28 | 7.5 High |
| Booking logic flaw in Easy!Appointments v1.5.1 allows unauthenticated attackers to create appointments with excessively long durations, causing a denial of service by blocking all future booking availability. | ||||
| CVE-2025-63388 | 2 Dify, Langgenius | 2 Dify, Dify | 2026-01-28 | 9.1 Critical |
| A Cross-Origin Resource Sharing (CORS) misconfiguration vulnerability exists in Dify v1.9.1 in the /console/api/system-features endpoint. The endpoint implements an overly permissive CORS policy that reflects arbitrary Origin headers and sets Access-Control-Allow-Credentials: true, allowing any external domain to make authenticated cross-origin requests. NOTE: the Supplier disputes this, providing the rationale of "sending requests with credentials does not provide any additional access compared to unauthenticated requests." | ||||
| CVE-2025-36911 | 1 Google | 1 Android | 2026-01-28 | 7.1 High |
| In key-based pairing, there is a possible ID due to a logic error in the code. This could lead to remote (proximal/adjacent) information disclosure of user's conversations and location with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-22251 | 2 Weblate, Weblateorg | 2 Wlc, Wlc | 2026-01-27 | 5.3 Medium |
| wlc is a Weblate command-line client using Weblate's REST API. Prior to 1.17.0, wlc supported providing unscoped API keys in the setting. This practice was discouraged for years, but the code was never removed. This might cause the API key to be leaked to different servers. | ||||
| CVE-2025-58589 | 1 Sick | 4 Baggage Analytics, Logistic Diagnostic Analytics, Package Analytics and 1 more | 2026-01-27 | 2.7 Low |
| When an error occurs in the application a full stacktrace is provided to the user. The stacktrace lists class and method names as well as other internal information. An attacker thus receives information about the technology used and the structure of the application. | ||||
| CVE-2025-20939 | 1 Samsung | 11 Galaxy Watch, Galaxy Watch 4, Galaxy Watch 4 Classic and 8 more | 2026-01-27 | 5.4 Medium |
| Improper authorization in wireless download protocol in Galaxy Watch prior to SMR Apr-2025 Release 1 allows physical attackers to update device unique identifier of Watch devices. | ||||
| CVE-2023-31595 | 1 Icrealtime | 2 Icip-p2012t, Icip-p2012t Firmware | 2026-01-27 | 7.5 High |
| IC Realtime ICIP-P2012T 2.420 is vulnerable to Incorrect Access Control via unauthenticated port access. | ||||
| CVE-2025-58581 | 1 Sick | 1 Enterprise Analytics | 2026-01-27 | 4.3 Medium |
| When an error occurs in the application a full stacktrace is provided to the user. The stacktrace lists class and method names as well as other internal information. An attacker can thus obtain information about the technology used and the structure of the application. | ||||
| CVE-2025-49200 | 1 Sick | 1 Field Analytics | 2026-01-26 | 6.5 Medium |
| The created backup files are unencrypted, making the application vulnerable for gathering sensitive information by downloading and decompressing the backup files. | ||||
| CVE-2025-39202 | 1 Hitachienergy | 1 Microscada X Sys600 | 2026-01-26 | 7.3 High |
| A vulnerability exists in in the Monitor Pro interface of the MicroSCADA X SYS600 product. An authenticated user with low privileges can see and overwrite files causing information leak and data corruption. | ||||
| CVE-2025-39204 | 1 Hitachienergy | 1 Microscada X Sys600 | 2026-01-26 | 6.5 Medium |
| A vulnerability exists in the Web interface of the MicroSCADA X SYS600 product. The filtering query in the Web interface can be malformed, so returning data can leak unauthorized information to the user. | ||||
| CVE-2022-50494 | 1 Linux | 1 Linux Kernel | 2026-01-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash When CPU 0 is offline and intel_powerclamp is used to inject idle, it generates kernel BUG: BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687 caller is debug_smp_processor_id+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace: <TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_id+0x17/0x20 powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp] ... ... Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpus_read_lock(), hence the above warning. Use get_cpu() instead of smp_processor_id() to avoid this BUG. [ rjw: Subject edits ] | ||||
| CVE-2022-50493 | 1 Linux | 1 Linux Kernel | 2026-01-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash when I/O abort times out While performing CPU hotplug, a crash with the following stack was seen: Call Trace: qla24xx_process_response_queue+0x42a/0x970 [qla2xxx] qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx] qla_nvme_post_cmd+0x166/0x240 [qla2xxx] nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc] blk_mq_dispatch_rq_list+0x17b/0x610 __blk_mq_sched_dispatch_requests+0xb0/0x140 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x35/0x90 __blk_mq_delay_run_hw_queue+0x161/0x180 blk_execute_rq+0xbe/0x160 __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core] nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics] nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc] nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc] process_one_work+0x1e8/0x3c0 On abort timeout, completion was called without checking if the I/O was already completed. Verify that I/O and abort request are indeed outstanding before attempting completion. | ||||
| CVE-2022-50483 | 1 Linux | 1 Linux Kernel | 2026-01-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: enetc: avoid buffer leaks on xdp_do_redirect() failure Before enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each software BD in the RX ring between index orig_i and i can have one of 2 refcount values on its page. We are the owner of the current buffer that is being processed, so the refcount will be at least 1. If the current owner of the buffer at the diametrically opposed index in the RX ring (i.o.w, the other half of this page) has not yet called kfree(), this page's refcount could even be 2. enetc_page_reusable() in enetc_flip_rx_buff() tests for the page refcount against 1, and [ if it's 2 ] does not attempt to reuse it. But if enetc_flip_rx_buff() is put after the xdp_do_redirect() call, the page refcount can have one of 3 values. It can also be 0, if there is no owner of the other page half, and xdp_do_redirect() for this buffer ran so far that it triggered a flush of the devmap/cpumap bulk queue, and the consumers of those bulk queues also freed the buffer, all by the time xdp_do_redirect() returns the execution back to enetc. This is the reason why enetc_flip_rx_buff() is called before xdp_do_redirect(), but there is a big flaw with that reasoning: enetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of the enetc_page_reusable() branch, and if xdp_do_redirect() returns an error, we call enetc_xdp_free(), which does not deal gracefully with that. In fact, what happens is quite special. The page refcounts start as 1. enetc_flip_rx_buff() figures they're reusable, transfers these rx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), and bumps the refcount to 2. When xdp_do_redirect() later returns an error, we call the no-op enetc_xdp_free(), but we still haven't lost the reference to that page. A copy of it is still at rx_ring->next_to_alloc, but that has refcount 2 (and there are no concurrent owners of it in flight, to drop the refcount). What really kills the system is when we'll flip the rx_swbd->page the second time around. With an updated refcount of 2, the page will not be reusable and we'll really leak it. Then enetc_new_page() will have to allocate more pages, which will then eventually leak again on further errors from xdp_do_redirect(). The problem, summarized, is that we zeroize rx_swbd->page before we're completely done with it, and this makes it impossible for the error path to do something with it. Since the packet is potentially multi-buffer and therefore the rx_swbd->page is potentially an array, manual passing of the old pointers between enetc_flip_rx_buff() and enetc_xdp_free() is a bit difficult. For the sake of going with a simple solution, we accept the possibility of racing with xdp_do_redirect(), and we move the flip procedure to execute only on the redirect success path. By racing, I mean that the page may be deemed as not reusable by enetc (having a refcount of 0), but there will be no leak in that case, either. Once we accept that, we have something better to do with buffers on XDP_REDIRECT failure. Since we haven't performed half-page flipping yet, we won't, either (and this way, we can avoid enetc_xdp_free() completely, which gives the entire page to the slab allocator). Instead, we'll call enetc_xdp_drop(), which will recycle this half of the buffer back to the RX ring. | ||||