Vulnerabilities exploitable today
369,598in current view
Single score combining CVSS, KEV membership and EPSS. Every CVE with its own record — timeline from publication to active exploitation.
In KEV catalog1,695
New KEV · 24H0
Exploit Today ≥ 701,638
Distribution · last window
- Critical2,115
- High7,606
- Medium5,692
- Low556
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-26201—21.3%
——6——CVE-2025-20298—21.3%
——6——CVE-2026-796587.5 HIG21.3%
——6Ech0 before 5.0.1 does not impose any size or shape limit on the Accept-Language header processed by its i18n middleware, which runs on every HTTP request. The header is passed unfiltered to go-i18n's NewLocalizer, which internally calls golang.org/x/text/language.ParseAcceptLanguage. The CVE-2022-32149 mitigation in x/text caps '-' characters but not '_' characters, which the parser aliases to '-', allowing quadratic-time parsing to be triggered with a large header (up to Go's default 1 MiB) built from underscore separators. An unauthenticated attacker can send such requests to consume roughly 1.5 seconds of CPU each, and concurrent requests can saturate a multi-core server (denial of service).7dCVE-2026-95807.3 HIG21.3%
——6A vulnerability was determined in JeecgBoot up to 3.9.1. The affected element is the function LoginController.selectDepart of the file /sys/selectDepart. This manipulation causes improper access controls. Remote exploitation of the attack is possible. The exploit has been publicly disclosed and may be utilized. Upgrading to version 3.9.2 is sufficient to fix this issue. It is suggested to upgrade the affected component.46dCVE-2024-54123—21.3%
——6——CVE-2025-4537—21.3%
——6——CVE-2024-12460—21.3%
——6——CVE-2024-416246.3 MED21.3%
——6Incorrect access control in Himalaya Xiaoya nano smart speaker rom_version 1.6.96 allows a remote attacker to have an unspecified impact.61dCVE-2022-4988—21.3%
——6——CVE-2026-770787.5 HIG21.3%
——6multer is a middleware for handling multipart/form-data in Node.js. A small multipart request containing two specially crafted text field names can cause an uncaught RangeError (Invalid array length) that terminates the Node.js process. The first field uses a very large numeric array index to allocate a maximum-length sparse array, and a second field then pushes past that length, which throws inside the append-field dependency and is not caught by multer. All versions before 2.3.0 are affected, and the issue is a remotely triggerable denial of service. The issue is fixed in multer 2.3.0. Upgrade to multer 2.3.0 to remediate.6dCVE-2025-399489.8 CRI21.3%
——6In the Linux kernel, the following vulnerability has been resolved:
ice: fix Rx page leak on multi-buffer frames
The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each
buffer in the current frame. This function was introduced as part of
handling multi-buffer XDP support in the ice driver.
It works by iterating over the buffers from first_desc up to 1 plus the
total number of fragments in the frame, cached from before the XDP program
was executed.
If the hardware posts a descriptor with a size of 0, the logic used in
ice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added
as fragments in ice_add_xdp_frag. Since the buffer isn't counted as a
fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't
call ice_put_rx_buf().
Because we don't call ice_put_rx_buf(), we don't attempt to re-use the
page or free it. This leaves a stale page in the ring, as we don't
increment next_to_alloc.
The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented
properly, and that it always points to a buffer with a NULL page. Since
this function doesn't check, it will happily recycle a page over the top
of the next_to_alloc buffer, losing track of the old page.
Note that this leak only occurs for multi-buffer frames. The
ice_put_rx_mbuf() function always handles at least one buffer, so a
single-buffer frame will always get handled correctly. It is not clear
precisely why the hardware hands us descriptors with a size of 0 sometimes,
but it happens somewhat regularly with "jumbo frames" used by 9K MTU.
To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on
all buffers between first_desc and next_to_clean. Borrow the logic of a
similar function in i40e used for this same purpose. Use the same logic
also in ice_get_pgcnts().
Instead of iterating over just the number of fragments, use a loop which
iterates until the current index reaches to the next_to_clean element just
past the current frame. Unlike i40e, the ice_put_rx_mbuf() function does
call ice_put_rx_buf() on the last buffer of the frame indicating the end of
packet.
For non-linear (multi-buffer) frames, we need to take care when adjusting
the pagecnt_bias. An XDP program might release fragments from the tail of
the frame, in which case that fragment page is already released. Only
update the pagecnt_bias for the first descriptor and fragments still
remaining post-XDP program. Take care to only access the shared info for
fragmented buffers, as this avoids a significant cache miss.
The xdp_xmit value only needs to be updated if an XDP program is run, and
only once per packet. Drop the xdp_xmit pointer argument from
ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function
directly. This avoids needing to pass the argument and avoids an extra
bit-wise OR for each buffer in the frame.
Move the increment of the ntc local variable to ensure its updated *before*
all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic
requires the index of the element just after the current frame.
Now that we use an index pointer in the ring to identify the packet, we no
longer need to track or cache the number of fragments in the rx_ring.40dCVE-2024-47507—21.3%
——6——CVE-2026-633009.9 CRI21.3%
——6An improper validation vulnerability in the instancePostMigration function in lxd/instance_post.go of LXD allows an authenticated attacker with can_create_instances permissions on a restricted project to bypass project-level security restrictions. When migrating an instance between projects, LXD fails to validate the instance's configuration against the target project's enforced restrictions (such as restricted.containers.lowlevel, restricted.devices.*, and restricted.networks.access). An attacker can exploit this by creating a disallowed or high-privilege instance in an unrestricted project and subsequently moving it into the restricted project.11dCVE-2022-41927—21.3%
——6——CVE-2026-4563—21.3%
——6——CVE-2025-32385—21.3%
——6——CVE-2026-763905.3 MED21.3%
——6In Cisco Talos Intelligence for Enterprise Security Cloud versions below 1.0.3, an unauthenticated user could access the add-on OpenAPI specification through Splunk Web static file paths. The exposed specification could allow for reconnaissance of the add-on Representational State Transfer (REST) API endpoints and authentication model. The vulnerability is possible because the generated OpenAPI specification is packaged in a static file path that Splunk Web serves without authentication. For more information see Deploy Cisco Talos Intelligence for Splunk Enterprise Security (https://help.splunk.com/en/splunk-enterprise-security-8/user-guide/8.0/introduction/deploy-cisco-talos-intelligence-for-splunk-enterprise-security-cloud-only) in the Splunk documentation.17dCVE-2022-30627—21.3%
——6——CVE-2025-47001—21.3%
——6——CVE-2025-382877.5 HIG21.3%
——6In the Linux kernel, the following vulnerability has been resolved:
IB/cm: Drop lockdep assert and WARN when freeing old msg
The send completion handler can run after cm_id has advanced to another
message. The cm_id lock is not needed in this case, but a recent change
re-used cm_free_priv_msg(), which asserts that the lock is held and
WARNs if the cm_id's currently outstanding msg is different than the one
being freed.40dCVE-2026-210616.5 MED21.3%
——6Improper input validation in Samsung Dialer prior to SMR Aug-2026 Release 1 allows remote attackers to access SIM related functions. User interaction is required for triggering this vulnerability.20dCVE-2024-36987—21.3%
——6——CVE-2026-4005—21.3%
——6——CVE-2026-99698.8 HIG21.3%
——6Insufficient validation of untrusted input in ANGLE in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: High)49dCVE-2018-0392—21.3%
——6——CVE-2024-5317—21.3%
——6——CVE-2024-21599—21.3%
——6——CVE-2025-34201—21.3%
——6——CVE-2024-23224—21.3%
——6——CVE-2018-20008—21.3%
——6——CVE-2017-0316—21.3%
——6——CVE-2026-613067.1 HIG21.3%
——6Vulnerability in the Oracle Complex Maintenance, Repair and Overhaul product of Oracle E-Business Suite (component: Production). Supported versions that are affected are 12.2.3-12.2.15. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Complex Maintenance, Repair and Overhaul. While the vulnerability is in Oracle Complex Maintenance, Repair and Overhaul, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Complex Maintenance, Repair and Overhaul accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Complex Maintenance, Repair and Overhaul. CVSS 3.1 Base Score 7.1 (Confidentiality and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:L).7dCVE-2026-714249.6 CRI21.3%
——6Onyx is an open-source AI platform. Prior to 3.1.10, 3.2.14, and 4.0.0, Onyx's GET /api/mcp/servers and GET /api/mcp/servers/persona/{persona_id} endpoints expose another user's OAuth Authorization header because OnyxTokenStorage.set_tokens and OnyxTokenStorage.set_client_info in backend/onyx/server/features/mcp/api.py copy per-user tokens into a shared admin MCPConnectionConfig row and _db_mcp_server_to_api_mcp_server returns that row through auth_template.headers to any BASIC_ACCESS user. This issue is fixed in versions 3.1.10, 3.2.14, and 4.0.0.20dCVE-2025-0516—21.3%
——6——CVE-2008-6561—21.3%
——6——CVE-2026-684338.6 HIG21.3%
——6In the Linux kernel, the following vulnerability has been resolved:
libceph: bound get_version reply decode to front len
handle_get_version_reply() uses msg->front_alloc_len as the decode
boundary for MON_GET_VERSION_REPLY. That is the size of the reused
reply buffer, not the number of bytes actually received.
A truncated reply can therefore pass ceph_decode_need() and decode the
second u64 from stale tail bytes left in the buffer by an earlier
message, causing an uninitialized memory read.
Use msg->front.iov_len as the receive-side decode boundary, matching
other libceph reply handlers and limiting decoding to the bytes that
were actually read from the wire.20dCVE-2026-6427—21.3%
——6——CVE-2024-21739—21.3%
——6——CVE-2012-0098—21.3%
——6——CVE-2026-98798.8 HIG21.3%
——6Out of bounds write in ANGLE in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: Critical)49d