Vulnerabilities exploitable today
354,684in 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,656
New KEV · 24H0
Exploit Today ≥ 701,601
Distribution · last window
- Critical2,622
- High9,423
- Medium7,591
- Low711
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2025-64380—5.2%
——2——CVE-2025-38557—5.2%
——2——CVE-2026-1858—5.2%
——2——CVE-2025-9201—5.2%
——2——CVE-2020-11602—5.2%
——2——CVE-2025-69353—5.2%
——2——CVE-2026-5818—5.2%
——2——CVE-2025-69354—5.2%
——2——CVE-2025-55096—5.2%
——2——CVE-2023-21432—5.2%
——2——CVE-2025-397877.8 HIG5.2%
——2In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: mdt_loader: Ensure we don't read past the ELF header
When the MDT loader is used in remoteproc, the ELF header is sanitized
beforehand, but that's not necessary the case for other clients.
Validate the size of the firmware buffer to ensure that we don't read
past the end as we iterate over the header. e_phentsize and e_shentsize
are validated as well, to ensure that the assumptions about step size in
the traversal are valid.2dCVE-2025-39788—5.2%
——2——CVE-2026-24371—5.2%
——2——CVE-2022-27826—5.2%
——2——CVE-2025-38071—5.2%
——2——CVE-2026-21018—5.2%
——2——CVE-2021-0357—5.2%
——2——CVE-2025-26926—5.2%
——2——CVE-2024-1395—5.2%
——2——CVE-2025-10752—5.2%
——2——CVE-2025-1926—5.2%
——2——CVE-2026-24520—5.2%
——2——CVE-2025-46775—5.2%
——2——CVE-2025-387147.8 HIG5.2%
——2In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()
The hfsplus_bnode_read() method can trigger the issue:
[ 174.852007][ T9784] ==================================================================
[ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360
[ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784
[ 174.854059][ T9784]
[ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)
[ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 174.854286][ T9784] Call Trace:
[ 174.854289][ T9784] <TASK>
[ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0
[ 174.854305][ T9784] print_report+0xd0/0x660
[ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610
[ 174.854323][ T9784] ? __phys_addr+0xe8/0x180
[ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360
[ 174.854337][ T9784] kasan_report+0xc6/0x100
[ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360
[ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360
[ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380
[ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10
[ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0
[ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310
[ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40
[ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0
[ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0
[ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10
[ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10
[ 174.854436][ T9784] ? __asan_memset+0x23/0x50
[ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320
[ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10
[ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0
[ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40
[ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0
[ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10
[ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0
[ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10
[ 174.854525][ T9784] ? down_write+0x148/0x200
[ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10
[ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0
[ 174.854549][ T9784] do_unlinkat+0x490/0x670
[ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10
[ 174.854565][ T9784] ? __might_fault+0xbc/0x130
[ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550
[ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110
[ 174.854592][ T9784] do_syscall_64+0xc9/0x480
[ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167
[ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08
[ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057
[ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167
[ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50
[ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40
[ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0
[ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 174.854658][ T9784] </TASK>
[ 174.854661][ T9784]
[ 174.879281][ T9784] Allocated by task 9784:
[ 174.879664][ T9784] kasan_save_stack+0x20/0x40
[ 174.880082][ T9784] kasan_save_track+0x14/0x30
[ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0
[ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550
[ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890
[ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10
[ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520
[ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3
---truncated---2dCVE-2025-397147.8 HIG5.2%
——2In the Linux kernel, the following vulnerability has been resolved:
media: usbtv: Lock resolution while streaming
When an program is streaming (ffplay) and another program (qv4l2)
changes the TV standard from NTSC to PAL, the kernel crashes due to trying
to copy to unmapped memory.
Changing from NTSC to PAL increases the resolution in the usbtv struct,
but the video plane buffer isn't adjusted, so it overflows.
[hverkuil: call vb2_is_busy instead of vb2_is_streaming]2dCVE-2025-386777.8 HIG5.2%
——2In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid out-of-boundary access in dnode page
As Jiaming Zhang reported:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x1c1/0x2a0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x17e/0x800 mm/kasan/report.c:480
kasan_report+0x147/0x180 mm/kasan/report.c:593
data_blkaddr fs/f2fs/f2fs.h:3053 [inline]
f2fs_data_blkaddr fs/f2fs/f2fs.h:3058 [inline]
f2fs_get_dnode_of_data+0x1a09/0x1c40 fs/f2fs/node.c:855
f2fs_reserve_block+0x53/0x310 fs/f2fs/data.c:1195
prepare_write_begin fs/f2fs/data.c:3395 [inline]
f2fs_write_begin+0xf39/0x2190 fs/f2fs/data.c:3594
generic_perform_write+0x2c7/0x910 mm/filemap.c:4112
f2fs_buffered_write_iter fs/f2fs/file.c:4988 [inline]
f2fs_file_write_iter+0x1ec8/0x2410 fs/f2fs/file.c:5216
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x546/0xa90 fs/read_write.c:686
ksys_write+0x149/0x250 fs/read_write.c:738
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xf3/0x3d0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The root cause is in the corrupted image, there is a dnode has the same
node id w/ its inode, so during f2fs_get_dnode_of_data(), it tries to
access block address in dnode at offset 934, however it parses the dnode
as inode node, so that get_dnode_addr() returns 360, then it tries to
access page address from 360 + 934 * 4 = 4096 w/ 4 bytes.
To fix this issue, let's add sanity check for node id of all direct nodes
during f2fs_get_dnode_of_data().2dCVE-2026-2832—5.2%
——2——CVE-2024-52392—5.2%
——2——CVE-2026-24198—5.2%
——2——CVE-2025-38648—5.2%
——2——CVE-2024-34676—5.2%
——2——CVE-2026-64013—5.2%
——2In the Linux kernel, the following vulnerability has been resolved:
ACPI: button: Fix ACPI GPE handler leak during removal
Commit a7e23ec17fee ("ACPI: button: Install notifier for system events
as well") changed the ACPI notify handler type for ACPI buttons to
ACPI_ALL_NOTIFY, but it forgot to update acpi_button_remove() to reflect
that change. This leads to leaking the notify handler past driver
removal, which may cause a kernel crash to occur if ACPI notify on
the given device is triggered after removing the driver, and causes a
subsequent probe of the given device with the same driver to fail.
Address this by updating the acpi_remove_notify_handler() call in
acpi_button_remove() as appropriate.2dCVE-2026-134344.9 MED5.2%
——2A flaw was found in KubeVirt's network annotation generator. When a tenant creates a VirtualMachineInstance with a Multus network configuration, the supplied networkName value is written verbatim into the launcher pod's v1.multus-cni.io/default-network annotation without format validation or sanitization. The only admission check rejects empty strings; no DNS-1123 format validation, JSON detection, or special character rejection is performed. When the ExternalNetResourceInjection Beta feature gate is enabled (off by default, cluster-admin only), the NAD lookup that would otherwise catch malformed names is skipped by design. A tenant with kubevirt.io:edit permissions can inject a JSON-formatted NetworkSelectionElement array specifying an arbitrary namespace, NAD name, static IP address, and MAC address. Multus on the node parses this JSON and attaches the launcher pod to the specified network attachment in any namespace, enabling cross-namespace network access and IP/MAC impersonation on network segments normally segregated from tenant workloads. The ExternalNetResourceInjection feature gate was introduced in KubeVirt v1.8.0 (first shipped in OpenShift Virtualization 4.21).25dCVE-2026-64019—5.2%
——2In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: fix dma mapping leak on data setup error
We're leaking the initial DMA mapping during iteration if we fail to
allocate the tracking descriptor for both PRP and SGL. Unmap the
iterator directly; we can't use the existing unmap helper because it
depends on the tracking descriptor being successfully allocated, so a
new one for an in-use iterator is provided.
The mappings were also leaking when the driver detects an invalid
bio_vec when mapping PRPs, so fix that too.2dCVE-2026-457024.4 MED5.2%
——2OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. Starting in version 4.3.0 and prior to version 4.11.0, a type confusion vulnerability exists in OP-TEE OS when processing an FFA_MEM_SHARE request from the normal world. This only applies when OP-TEE is configured as an SPMC for S-EL0 SPs, that is, with `CFG_CORE_SEL1_SPMC=y` and `CFG_SECURE_PARTITION=y`. Version 4.11.0 fixes the issue.9dCVE-2025-47761—5.2%
——2——CVE-2026-3236—5.2%
——2——CVE-2020-0419—5.2%
——2——CVE-2025-64383—5.2%
——2——CVE-2025-36355—5.2%
——2——