Vulnerabilities exploitable today
351,724in 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,651
New KEV · 24H0
Exploit Today ≥ 701,587
Distribution · last window
- Critical1,765
- High5,628
- Medium4,518
- Low412
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-30902—1.6%
——0——CVE-2025-71155—1.6%
——0——CVE-2026-43228—1.6%
——0——CVE-2023-21106—1.6%
——0——CVE-2022-20111—1.6%
——0——CVE-2026-13523—1.6%
——0——CVE-2024-49784—1.6%
——0——CVE-2026-463117.8 HIG1.6%
——0In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/userq: fix access to stale wptr mapping
Use drm_exec to take both locks i.e vm root bo and
wptr_obj bo to access the mapping data properly.
This fixes the security issue of unmap the wptr_obj while
a queue creation is in progress and passing other
bo at same address.
(cherry picked from commit 1fc6c8ab45dbee096469c08c13f6099d57a52d6c)14dCVE-2021-0413—1.6%
——0——CVE-2025-33235—1.6%
——0——CVE-2026-43204—1.6%
——0——CVE-2024-20280—1.6%
——0——CVE-2021-39810—1.6%
——0——CVE-2022-20194—1.6%
——0——CVE-2025-48510—1.6%
——0——CVE-2026-44118—1.6%
——0——CVE-2026-6192—1.6%
——0——CVE-2026-53465—1.6%
——0——CVE-2026-40977—1.6%
——0——CVE-2026-43192—1.6%
——0——CVE-2026-532065.5 MED1.6%
——0In the Linux kernel, the following vulnerability has been resolved:
accel/ivpu: Add bounds check for firmware runtime memory
Validate that the firmware runtime memory specified in the image
header is properly aligned and sized to hold the firmware image.
This prevents errors during memory allocation and image transfer.19dCVE-2026-43191—1.6%
——0——CVE-2025-2509—1.6%
——0——CVE-2021-0614—1.6%
——0——CVE-2021-0613—1.6%
——0——CVE-2020-27035—1.6%
——0——CVE-2026-43174—1.6%
——0——CVE-2026-23194—1.6%
——0——CVE-2026-533807.8 HIG1.6%
——0In the Linux kernel, the following vulnerability has been resolved:
media: rzv2h-ivc: Fix concurrent buffer list access
The list of buffers (`rzv2h_ivc::buffers.queue`) is protected by a
spinlock (`rzv2h_ivc::buffers.lock`). However, in
`rzv2h_ivc_transfer_buffer()`, which runs in a separate workqueue, the
`list_del()` call is executed without holding the spinlock, which makes
it possible for the list to be concurrently modified
Fix that by removing a buffer from the list in the lock protected section.
[assign ivc->buffers.curr in critical section as reported by Barnabas]2dCVE-2021-0615—1.6%
——0——CVE-2026-532435.5 MED1.6%
——0In the Linux kernel, the following vulnerability has been resolved:
rseq: Fix using an uninitialized stack variable in rseq_exit_user_update()
There is an bug in which an uninitialized stack variable is used in
rseq_exit_user_update() as reported by syzbot:
BUG: KMSAN: kernel-infoleak in rseq_set_ids_get_csaddr include/linux/rseq_entry.h:502 [inline]
The local variable:
struct rseq_ids ids = {
.cpu_id = task_cpu(t),
.mm_cid = task_mm_cid(t),
.node_id = cpu_to_node(ids.cpu_id),
};
According to the C standard, the evaluation order of expressions in an
initializer list is indeterminately sequenced. The compiler (Clang, in
this KMSAN build) evaluates `cpu_to_node(ids.cpu_id)` *before*
`ids.cpu_id` is initialized with `task_cpu(t)`.
This is fixed by moving the assignment of ids.node_id outside the
structure initialization.14dCVE-2026-43193—1.6%
——0——CVE-2024-40653—1.6%
——0——CVE-2026-463307.8 HIG1.6%
——0In the Linux kernel, the following vulnerability has been resolved:
Revert "net/smc: Introduce TCP ULP support"
This reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.
As reported by Al Viro, the TCP ULP support for SMC is fundamentally
broken. The implementation attempts to convert an active TCP socket
into an SMC socket by modifying the underlying `struct file`, dentry,
and inode in-place, which violates core VFS invariants that assume
these structures are immutable for an open file, creating a risk of
use after free errors and general system instability.
Given the severity of this design flaw and the fact that cleaner
alternatives (e.g., LD_PRELOAD, BPF) exist for legacy application
transparency, the correct course of action is to remove this feature
entirely.13dCVE-2026-55669—1.6%
——0——CVE-2023-21470—1.6%
——0——CVE-2023-20708—1.6%
——0——CVE-2025-27812—1.6%
——0——CVE-2015-0849—1.6%
——0——CVE-2023-21469—1.6%
——0——