Vulnerabilities exploitable today
351,920in 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
- Critical1,901
- High6,163
- Medium4,997
- Low479
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-43090—2.4%
——1——CVE-2026-23062—2.4%
——1——CVE-2026-31592—2.4%
——1——CVE-2022-50149—2.4%
——1——CVE-2026-43086—2.4%
——1——CVE-2026-43088—2.4%
——1——CVE-2026-43036—2.4%
——1——CVE-2026-43129—2.4%
——1——CVE-2026-23369—2.4%
——1——CVE-2026-430105.5 MED2.4%
——1In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject sleepable kprobe_multi programs at attach time
kprobe.multi programs run in atomic/RCU context and cannot sleep.
However, bpf_kprobe_multi_link_attach() did not validate whether the
program being attached had the sleepable flag set, allowing sleepable
helpers such as bpf_copy_from_user() to be invoked from a non-sleepable
context.
This causes a "sleeping function called from invalid context" splat:
BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo
preempt_count: 1, expected: 0
RCU nest depth: 2, expected: 0
Fix this by rejecting sleepable programs early in
bpf_kprobe_multi_link_attach(), before any further processing.19dCVE-2026-23088—2.4%
——1——CVE-2026-43354—2.4%
——1——CVE-2026-43394—2.4%
——1——CVE-2026-43161—2.4%
——1——CVE-2026-43413—2.4%
——1——CVE-2026-46230—2.4%
——1——CVE-2026-43318—2.4%
——1——CVE-2026-31591—2.4%
——1——CVE-2026-31647—2.4%
——1——CVE-2026-43092—2.4%
——1——CVE-2024-31335—2.4%
——1——CVE-2026-46007—2.4%
——1——CVE-2026-31639—2.4%
——1——CVE-2026-23464—2.4%
——1——CVE-2026-23140—2.4%
——1——CVE-2025-30513—2.4%
——1——CVE-2026-31645—2.4%
——1——CVE-2023-35890—2.4%
——1——CVE-2026-532557.1 HIG2.4%
——1In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: validate advertising TLV before type checks
tlv_data_is_valid() reads each advertising data field length from
data[i], then inspects data[i + 1] for managed EIR types before
checking that the current field still fits inside the supplied buffer.
A malformed field whose length byte is the last byte of the buffer can
therefore make the parser read one byte past the advertising data.
KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING
request reached that path:
BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid()
Read of size 1
Call trace:
tlv_data_is_valid()
add_advertising()
hci_mgmt_cmd()
hci_sock_sendmsg()
Move the existing element-length check before any type-octet inspection
so each non-empty element is proven to contain its type byte before the
parser looks at data[i + 1].14dCVE-2026-24066—2.4%
——1——CVE-2026-43372—2.4%
——1——CVE-2026-46073—2.4%
——1——CVE-2026-23316—2.4%
——1——CVE-2026-45950—2.4%
——1——CVE-2026-31458—2.4%
——1——CVE-2026-43444—2.4%
——1——CVE-2025-713145.5 MED2.4%
——1In the Linux kernel, the following vulnerability has been resolved:
drm/panthor: Recover from panthor_gpu_flush_caches() failures
We have seen a few cases where the whole memory subsystem is blocked
and flush operations never complete. When that happens, we want to:
- schedule a reset, so we can recover from this situation
- in the reset path, we need to reset the pending_reqs so we can send
new commands after the reset
- if more panthor_gpu_flush_caches() operations are queued after
the timeout, we skip them and return -EIO directly to avoid needless
waits (the memory block won't miraculously work again)
Note that we drop the WARN_ON()s because these hangs can be triggered
with buggy GPU jobs created by the UMD, and there's no way we can
prevent it. We do keep the error messages though.
v2:
- New patch
v3:
- Collect R-b
- Explicitly mention the fact we dropped the WARN_ON()s in the commit
message
v4:
- No changes9hCVE-2026-31723—2.4%
——1——CVE-2026-43397—2.4%
——1——CVE-2024-36352—2.4%
——1——