Vulnerabilities exploitable today
352,317in 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,653
New KEV · 24H0
Exploit Today ≥ 701,590
Distribution · last window
- Critical2,257
- High7,708
- Medium7,032
- Low663
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-602489.3 CRI2.9%
——1Vulnerability in the Oracle Coherence product of Oracle Fusion Middleware (component: Core). Supported versions that are affected are 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0 and 15.1.1.0.0. Easily exploitable vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle Coherence executes to compromise Oracle Coherence. While the vulnerability is in Oracle Coherence, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle Coherence. CVSS 3.1 Base Score 9.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).1dCVE-2026-129217.8 HIG2.9%
——1In AzeoTech DAQFactory versions 21.1 and prior, a Use After Free vulnerability can be exploited by an attacker using specially crafted .ctl files which can result in code execution.8dCVE-2026-46068—2.9%
——1——CVE-2026-530317.8 HIG2.9%
——1In the Linux kernel, the following vulnerability has been resolved:
bpf: Validate node_id in arena_alloc_pages()
arena_alloc_pages() accepts a plain int node_id and forwards it through
the entire allocation chain without any bounds checking.
Validate node_id before passing it down the allocation chain in
arena_alloc_pages().10dCVE-2025-55041—2.9%
——1——CVE-2025-21034—2.9%
——1——CVE-2025-38107—2.9%
——1——CVE-2026-43019—2.9%
——1——CVE-2026-48792—2.9%
——1——CVE-2022-20553—2.9%
——1——CVE-2026-572407.8 HIG2.9%
——1When the application opens a PDF file and JavaScript deletes the PDF fields, the subsequent logic still uses the old field pointers, resulting in invalid pointer references and causing the application to crash.16dCVE-2026-234487.8 HIG2.9%
——1In the Linux kernel, the following vulnerability has been resolved:
net: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds check
cdc_ncm_rx_verify_ndp16() validates that the NDP header and its DPE
entries fit within the skb. The first check correctly accounts for
ndpoffset:
if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp16)) > skb_in->len)
but the second check omits it:
if ((sizeof(struct usb_cdc_ncm_ndp16) +
ret * (sizeof(struct usb_cdc_ncm_dpe16))) > skb_in->len)
This validates the DPE array size against the total skb length as if
the NDP were at offset 0, rather than at ndpoffset. When the NDP is
placed near the end of the NTB (large wNdpIndex), the DPE entries can
extend past the skb data buffer even though the check passes.
cdc_ncm_rx_fixup() then reads out-of-bounds memory when iterating
the DPE array.
Add ndpoffset to the nframes bounds check and use struct_size_t() to
express the NDP-plus-DPE-array size more clearly.6hCVE-2025-14062—2.9%
——1——CVE-2026-43091—2.9%
——1——CVE-2026-31743—2.9%
——1——CVE-2026-50128—2.9%
——1——CVE-2025-13924—2.9%
——1——CVE-2025-40811—2.9%
——1——CVE-2026-622396.6 MED2.9%
——1FlashAttention through 2.8.3.post1, fixed in commit 0816ef1, contains a symlink attack vulnerability in the download_and_copy() function within hopper/setup.py that extracts NVIDIA toolchain archives without validating symlinks or filtering tar members. A local attacker can pre-plant a symlink in the predictable cache directory to redirect extracted binaries to an attacker-chosen location, enabling arbitrary file write with victim privileges during build time.9dCVE-2026-28196—2.9%
——1——CVE-2021-39621—2.9%
——1——CVE-2026-31506—2.9%
——1——CVE-2026-31729—2.9%
——1——CVE-2025-14168—2.9%
——1——CVE-2025-12190—2.9%
——1——CVE-2024-0139—2.9%
——1——CVE-2023-34046—2.9%
——1——CVE-2021-47869—2.9%
——1——CVE-2026-10530—2.9%
——1——CVE-2025-3442—2.9%
——1——CVE-2026-46001—2.9%
——1——CVE-2026-23361—2.9%
——1——CVE-2026-43250—2.9%
——1——CVE-2026-43007—2.9%
——1——CVE-2025-30506—2.9%
——1——CVE-2026-54555—2.9%
——1——CVE-2025-0136—2.9%
——1——CVE-2026-640267.8 HIG2.9%
——1In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg
This improves the fix for CVE-2026-43500.
Fix the pagecache corruption from in-place decryption of a DATA packet
transmitted locally by splice() by getting rid of the packet sharing in the
I/O thread and unconditionally extracting the packet content into a bounce
buffer in which the buffer is decrypted. recvmsg() (or the kernel
equivalent) then copies the data from the bounce buffer to the destination
buffer. The sk_buff then remains unmodified.
This has an additional advantage in that the packet is then arranged in the
buffer with the correct alignment required for the crypto algorithms to
process directly. The performance of the crypto does seem to be a little
faster and, surprisingly, the unencrypted performance doesn't seem to
change much - possibly due to removing complexity from the I/O thread.
Yet another advantage is that the I/O thread doesn't have to copy packets
which would slow down packet distribution, ACK generation, etc..
The buffer belongs to the call and is allocated initially at 2K,
sufficiently large to hold a whole jumbo subpacket, but the buffer will be
increased in size if needed. However, to take this work, MSG_PEEK may
cause a later packet to be decrypted into the buffer, in which case the
earlier one will need re-decrypting for a subsequent recvmsg().
Note that rx_pkt_offset may legitimately see 0 as a valid offset now, so
switch to using USHRT_MAX to indicate an invalid offset.
Note also that I would generally prefer to replace the buffers of the
current sk_buff with a new kmalloc'd buffer of the right size, ditching the
old data and frags as this makes the handling of MSG_PEEK easier and
removes the re-decryption issue, but this looks like quite a complicated
thing to achieve. skb_morph() looks half way to what I want, but I don't
want to have to allocate a new sk_buff.5dCVE-2026-234667.8 HIG2.9%
——1In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Open-code GGTT MMIO access protection
GGTT MMIO access is currently protected by hotplug (drm_dev_enter),
which works correctly when the driver loads successfully and is later
unbound or unloaded. However, if driver load fails, this protection is
insufficient because drm_dev_unplug() is never called.
Additionally, devm release functions cannot guarantee that all BOs with
GGTT mappings are destroyed before the GGTT MMIO region is removed, as
some BOs may be freed asynchronously by worker threads.
To address this, introduce an open-coded flag, protected by the GGTT
lock, that guards GGTT MMIO access. The flag is cleared during the
dev_fini_ggtt devm release function to ensure MMIO access is disabled
once teardown begins.
(cherry picked from commit 4f3a998a173b4325c2efd90bdadc6ccd3ad9a431)5hCVE-2025-21651—2.9%
——1——