Vulnerabilities exploitable today
354,835in 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,555
- High9,167
- Medium7,427
- Low691
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-44022—5.9%
——2——CVE-2025-68252—5.9%
——2——CVE-2025-217187.8 HIG5.9%
——2In the Linux kernel, the following vulnerability has been resolved:
net: rose: fix timer races against user threads
Rose timers only acquire the socket spinlock, without
checking if the socket is owned by one user thread.
Add a check and rearm the timers if needed.
BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174
Read of size 2 at addr ffff88802f09b82a by task swapper/0/0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x169/0x550 mm/kasan/report.c:489
kasan_report+0x143/0x180 mm/kasan/report.c:602
rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174
call_timer_fn+0x187/0x650 kernel/time/timer.c:1793
expire_timers kernel/time/timer.c:1844 [inline]
__run_timers kernel/time/timer.c:2418 [inline]
__run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430
run_timer_base kernel/time/timer.c:2439 [inline]
run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449
handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561
__do_softirq kernel/softirq.c:595 [inline]
invoke_softirq kernel/softirq.c:435 [inline]
__irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662
irq_exit_rcu+0x9/0x30 kernel/softirq.c:678
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049
</IRQ>3dCVE-2026-43859—5.9%
——2——CVE-2025-11940—5.9%
——2——CVE-2024-51647—5.9%
——2——CVE-2026-7859—5.9%
——2——CVE-2021-25391—5.9%
——2——CVE-2024-44105—5.9%
——2——CVE-2025-57942—5.9%
——2——CVE-2025-68233—5.9%
——2——CVE-2025-383967.8 HIG5.9%
——2In the Linux kernel, the following vulnerability has been resolved:
fs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass
Export anon_inode_make_secure_inode() to allow KVM guest_memfd to create
anonymous inodes with proper security context. This replaces the current
pattern of calling alloc_anon_inode() followed by
inode_init_security_anon() for creating security context manually.
This change also fixes a security regression in secretmem where the
S_PRIVATE flag was not cleared after alloc_anon_inode(), causing
LSM/SELinux checks to be bypassed for secretmem file descriptors.
As guest_memfd currently resides in the KVM module, we need to export this
symbol for use outside the core kernel. In the future, guest_memfd might be
moved to core-mm, at which point the symbols no longer would have to be
exported. When/if that happens is still unclear.3dCVE-2024-38660—5.9%
——2——CVE-2025-58441—5.9%
——2——CVE-2026-8564—5.9%
——2——CVE-2026-7814—5.9%
——2——CVE-2026-43860—5.9%
——2——CVE-2026-48990—5.9%
——2——CVE-2021-37690—5.9%
——2——CVE-2026-12607.8 HIG5.9%
——2Invalid memory access in Sentencepiece versions less than 0.2.1 when using a vulnerable model file, which is not created in the normal training procedure.18dCVE-2026-43360—5.9%
——2——CVE-2024-49561—5.9%
——2——CVE-2025-57960—5.9%
——2——CVE-2026-0924—5.9%
——2——CVE-2026-88817.5 HIG5.9%
——2Version 3.0.7 of the Securly Chrome Extension uses EVP_BytesToKey key derivation with MD5 and a single iteration for AES encryption. MD5 has been broken since 2004 and a single iteration provides no key stretching.11dCVE-2025-43251—5.9%
——2——CVE-2025-68235—5.9%
——2——CVE-2025-68237—5.9%
——2——CVE-2026-5712—5.9%
——2——CVE-2023-41775—5.9%
——2——CVE-2025-61604—5.9%
——2——CVE-2025-21063—5.9%
——2——CVE-2024-20944—5.9%
——2——CVE-2023-25947—5.9%
——2——CVE-2025-62781—5.9%
——2——CVE-2025-33102—5.9%
——2——CVE-2025-68343—5.9%
——2——CVE-2026-21008—5.9%
——2——CVE-2024-31078—5.9%
——2——CVE-2025-381417.8 HIG5.9%
——2In the Linux kernel, the following vulnerability has been resolved:
dm: fix dm_blk_report_zones
If dm_get_live_table() returned NULL, dm_put_live_table() was never
called. Also, it is possible that md->zone_revalidate_map will change
while calling this function. Only read it once, so that we are always
using the same value. Otherwise we might miss a call to
dm_put_live_table().
Finally, while md->zone_revalidate_map is set and a process is calling
blk_revalidate_disk_zones() to set up the zone append emulation
resources, it is possible that another process, perhaps triggered by
blkdev_report_zones_ioctl(), will call dm_blk_report_zones(). If
blk_revalidate_disk_zones() fails, these resources can be freed while
the other process is still using them, causing a use-after-free error.
blk_revalidate_disk_zones() will only ever be called when initially
setting up the zone append emulation resources, such as when setting up
a zoned dm-crypt table for the first time. Further table swaps will not
set md->zone_revalidate_map or call blk_revalidate_disk_zones().
However it must be called using the new table (referenced by
md->zone_revalidate_map) and the new queue limits while the DM device is
suspended. dm_blk_report_zones() needs some way to distinguish between a
call from blk_revalidate_disk_zones(), which must be allowed to use
md->zone_revalidate_map to access this not yet activated table, and all
other calls to dm_blk_report_zones(), which should not be allowed while
the device is suspended and cannot use md->zone_revalidate_map, since
the zone resources might be freed by the process currently calling
blk_revalidate_disk_zones().
Solve this by tracking the process that sets md->zone_revalidate_map in
dm_revalidate_zones() and only allowing that process to make use of it
in dm_blk_report_zones().3d