Vulnerabilities exploitable today
354,883in 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,556
- High9,177
- Medium7,435
- Low692
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2022-20574—6.3%
——2——CVE-2025-6459—6.3%
——2——CVE-2024-53736—6.3%
——2——CVE-2021-0307—6.3%
——2——CVE-2025-385427.8 HIG6.3%
——2In the Linux kernel, the following vulnerability has been resolved:
net: appletalk: Fix device refcount leak in atrtr_create()
When updating an existing route entry in atrtr_create(), the old device
reference was not being released before assigning the new device,
leading to a device refcount leak. Fix this by calling dev_put() to
release the old device reference before holding the new one.4dCVE-2018-11846—6.3%
——2——CVE-2020-0010—6.3%
——2——CVE-2026-64521—6.3%
——2In the Linux kernel, the following vulnerability has been resolved:
pinctrl: meson: amlogic-a4: fix deadlock issue
Accessing the pinconf-pins sysfs node may deadlock.
pinconf_pins_show() holds pctldev->mutex, and the platform driver
calls pinctrl_find_gpio_range_from_pin(), which tries to acquire
the same mutex again, leading to a deadlock.
Use pinctrl_find_gpio_range_from_pin_nolock() to fix this issue.9dCVE-2022-20590—6.3%
——2——CVE-2026-632624.3 MED6.3%
——2Missing Authorization (CWE-862) in Kibana can lead to unauthorized cross-space information disclosure via user-supplied input that circumvents space-level access control.11dCVE-2024-53734—6.3%
——2——CVE-2024-53727—6.3%
——2——CVE-2024-53726—6.3%
——2——CVE-2024-53724—6.3%
——2——CVE-2026-64230—6.3%
——2In the Linux kernel, the following vulnerability has been resolved:
regulator: tps65219: fix irq_data.rdev not being assigned
Commit 64a6b577490c ("regulator: tps65219: Remove debugging helper
function") removed the tps65219_get_rdev_by_name() helper along with
the irq_data.rdev assignment that depended on it. This left
irq_data.rdev uninitialized for all IRQs, causing undefined behavior
when regulator_notifier_call_chain() is called from the IRQ handler:
Internal error: Oops: 0000000096000004
pc : regulator_notifier_call_chain
lr : tps65219_regulator_irq_handler
Call trace:
regulator_notifier_call_chain
tps65219_regulator_irq_handler
handle_nested_irq
regmap_irq_thread
irq_thread_fn
irq_thread
kthread
ret_from_fork
Instead of restoring a dedicated lookup array, restructure the probe
function to combine regulator registration with IRQ registration in
the same loop. This way the rdev returned by devm_regulator_register()
is naturally available for assigning to irq_data.rdev without any
auxiliary data structure.
Non-regulator IRQs (SENSOR, TIMEOUT) that don't correspond to any
registered regulator are registered with rdev=NULL, and the IRQ handler
is protected with a NULL check to avoid crashing.4dCVE-2024-21063—6.3%
——2——CVE-2024-53725—6.3%
——2——CVE-2024-13317—6.3%
——2——CVE-2026-40917—6.3%
——2——CVE-2025-384087.8 HIG6.3%
——2In the Linux kernel, the following vulnerability has been resolved:
genirq/irq_sim: Initialize work context pointers properly
Initialize `ops` member's pointers properly by using kzalloc() instead of
kmalloc() when allocating the simulation work context. Otherwise the
pointers contain random content leading to invalid dereferencing.4dCVE-2025-41459—6.3%
——2——CVE-2023-39251—6.3%
——2——CVE-2026-43940—6.3%
——2——CVE-2026-632363.7 LOW6.3%
——2An improper access control vulnerability in
Koollab LMS allowed an
unauthenticated attacker to read another user's name, internal identifier,
scores, lesson status, lesson position, and cached lesson state via the SCORM
API endpoint.3dCVE-2024-28132—6.3%
——2——CVE-2025-59107—6.3%
——2——CVE-2023-31428—6.3%
——2——CVE-2025-31680—6.3%
——2——CVE-2022-49547—6.3%
——2——CVE-2026-57330—6.3%
——2——CVE-2021-0688—6.3%
——2——CVE-2019-6854—6.3%
——2——CVE-2025-40685—6.3%
——2——CVE-2026-24196—6.3%
——2——CVE-2017-6894—6.3%
——2——CVE-2016-20048—6.3%
——2——CVE-2025-386777.8 HIG6.3%
——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().4dCVE-2024-20370—6.3%
——2——CVE-2025-24148—6.3%
——2——CVE-2024-53718—6.3%
——2——