Vulnerabilities exploitable today
366,901in 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,685
New KEV · 24H0
Exploit Today ≥ 701,629
Distribution · last window
- Critical2,296
- High9,357
- Medium5,292
- Low508
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2025-68547—16.4%
——5——CVE-2026-30561—16.4%
——5——CVE-2019-0180—16.4%
——5——CVE-2024-44191—16.4%
——5——CVE-2025-24780—16.4%
——5——CVE-2025-30979—16.4%
——5——CVE-2024-20839—16.4%
——5——CVE-2024-5221—16.4%
——5——CVE-2013-4739—16.4%
——5——CVE-2026-30526—16.4%
——5——CVE-2019-0179—16.4%
——5——CVE-2026-32087—16.4%
——5——CVE-2023-53845—16.4%
——5——CVE-2024-35877—16.4%
——5——CVE-2025-0932—16.4%
——5——CVE-2025-63042—16.4%
——5——CVE-2022-489507.8 HIG16.4%
——5In the Linux kernel, the following vulnerability has been resolved:
perf: Fix perf_pending_task() UaF
Per syzbot it is possible for perf_pending_task() to run after the
event is free()'d. There are two related but distinct cases:
- the task_work was already queued before destroying the event;
- destroying the event itself queues the task_work.
The first cannot be solved using task_work_cancel() since
perf_release() itself might be called from a task_work (____fput),
which means the current->task_works list is already empty and
task_work_cancel() won't be able to find the perf_pending_task()
entry.
The simplest alternative is extending the perf_event lifetime to cover
the task_work.
The second is just silly, queueing a task_work while you know the
event is going away makes no sense and is easily avoided by
re-arranging how the event is marked STATE_DEAD and ensuring it goes
through STATE_OFF on the way down.26dCVE-2025-28967—16.4%
——5——CVE-2026-30557—16.4%
——5——CVE-2022-48545—16.4%
——5——CVE-2025-22779—16.4%
——5——CVE-2019-11092—16.4%
——5——CVE-2022-509676.1 MED16.4%
——5uBidAuction 2.0.1 contains a reflected cross-site scripting vulnerability in the tickets/manage module. The date_created, date_from, date_to, and created_at parameters in the filter functionality are not properly sanitized, allowing remote attackers to inject malicious scripts via crafted GET requests that execute in victims' browsers.36dCVE-2024-42550—16.4%
——5——CVE-2022-509666.1 MED16.4%
——5uBidAuction 2.0.1 contains a reflected cross-site scripting vulnerability in the news/manage module. The date_created, date_from, date_to, and created_at parameters in the filter functionality are not properly sanitized, allowing remote attackers to inject malicious scripts via crafted GET requests that execute in victims' browsers.40dCVE-2021-47119—16.4%
——5——CVE-2025-43304—16.4%
——5——CVE-2026-26360—16.4%
——5——CVE-2024-45054—16.4%
——5——CVE-2025-0546—16.4%
——5——CVE-2026-24906—16.4%
——5——CVE-2025-61763—16.4%
——5——CVE-2024-9230—16.4%
——5——CVE-2023-32542—16.4%
——5——CVE-2025-53485—16.4%
——5——CVE-2023-52705—16.4%
——5——CVE-2022-36924—16.4%
——5——CVE-2021-470827.8 HIG16.4%
——5In the Linux kernel, the following vulnerability has been resolved:
tun: avoid double free in tun_free_netdev
Avoid double free in tun_free_netdev() by moving the
dev->tstats and tun->security allocs to a new ndo_init routine
(tun_net_init()) that will be called by register_netdevice().
ndo_init is paired with the desctructor (tun_free_netdev()),
so if there's an error in register_netdevice() the destructor
will handle the frees.
BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1
Hardware name: Red Hat KVM, BIOS
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106
print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247
kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372
____kasan_slab_free mm/kasan/common.c:346 [inline]
__kasan_slab_free+0x107/0x120 mm/kasan/common.c:374
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:1723 [inline]
slab_free_freelist_hook mm/slub.c:1749 [inline]
slab_free mm/slub.c:3513 [inline]
kfree+0xac/0x2d0 mm/slub.c:4561
selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
security_tun_dev_free_security+0x4f/0x90 security/security.c:2342
tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215
netdev_run_todo+0x4df/0x840 net/core/dev.c:10627
rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112
__tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302
tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae26dCVE-2025-30947—16.4%
——5——CVE-2023-52858—16.4%
——5——