Vulnerabilities exploitable today
349,974in 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,647
New KEV · 24H0
Exploit Today ≥ 701,583
Distribution · last window
- Critical1,335
- High4,379
- Medium3,751
- Low298
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2024-21460—1.1%
——0——CVE-2022-20258—1.1%
——0——CVE-2025-21447—1.1%
——0——CVE-2022-26449—1.1%
——0——CVE-2022-26448—1.1%
——0——CVE-2025-27813—1.1%
——0——CVE-2025-54640—1.1%
——0——CVE-2025-54639—1.1%
——0——CVE-2025-46591—1.1%
——0——CVE-2023-53520—1.1%
——0——CVE-2022-20372—1.1%
——0——CVE-2026-45324—1.1%
——0——CVE-2026-0049—1.1%
——0——CVE-2026-533085.5 MED1.1%
——0In the Linux kernel, the following vulnerability has been resolved:
power: supply: max77705: Free allocated workqueue and fix removal order
Use devm interface for allocating workqueue to fix two bugs at the same
time:
1. Driver leaks the memory on remove(), because the workqueue is not
destroyed.
2. Driver allocates workqueue and then registers interrupt handlers
with devm interface. This means that probe error paths will not use a
reversed order, but first destroy the workqueue and then, via devm
release handlers, free the interrupt.
The interrupt handler schedules work on this exact workqueue, thus if
interrupt is hit in this short time window - after destroying
workqueue, but before devm() frees the interrupt - the schedulled
work will lead to use of freed memory.
Change is not equivalent in the workqueue itself: use non-legacy API
which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is
used to update power supply (power_supply_changed()) status, thus there
is no point to run it for memory reclaim. Note that dev_name() is not
directly used in second argument to prevent possible unlikely parsing
any "%" character in device name as format.13dCVE-2026-49860—1.1%
——0——CVE-2023-33060—1.1%
——0——CVE-2025-48911—1.1%
——0——CVE-2026-4930—1.1%
——0——CVE-2026-57298—1.1%
——0——CVE-2026-46257—1.1%
——0——CVE-2026-533135.5 MED1.1%
——0In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths
In dc_dmub_srv_log_diagnostic_data() and
dc_dmub_srv_enable_dpia_trace().
Both functions check:
if (!dc_dmub_srv || !dc_dmub_srv->dmub)
and then call DC_LOG_ERROR() inside that block.
DC_LOG_ERROR() uses dc_dmub_srv->ctx internally. So if
dc_dmub_srv is NULL, the logging itself can dereference a
NULL pointer and cause a crash.
Fix this by splitting the checks.
First check if dc_dmub_srv is NULL and return immediately.
Then check dc_dmub_srv->dmub and log the error only when
dc_dmub_srv is valid.
Fixes the below:
../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed 'dc_dmub_srv' could be null (see line 961)
../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed 'dc_dmub_srv' could be null (see line 1166)13dCVE-2025-39961—1.1%
——0——CVE-2022-26455—1.1%
——0——CVE-2025-21440—1.1%
——0——CVE-2023-42718—1.1%
——0——CVE-2026-23152—1.1%
——0——CVE-2026-62294—1.1%
——0Flameshot is powerful yet simple to use screenshot software. Prior to 14.0.0, the Open With feature wrote screenshots to a predictable temporary path and followed symlinks, creating a time-of-check to time-of-use race that allowed a local unprivileged attacker on the same machine to pre-plant a symlink and cause Flameshot to write PNG data through it, overwriting any file the victim user could write. This issue is fixed in version 14.0.0.4dCVE-2025-38675—1.1%
——0——CVE-2025-21437—1.1%
——0——CVE-2023-20548—1.1%
——0——CVE-2026-533045.5 MED1.1%
——0In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Resolve soft lockup issue when opening /dev/sgX
The parameter def_reserved_size defines the default buffer size reserved
for each Sg_fd and should be restricted to a range between 0 and 1,048,576
(see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the
function sg_proc_write_dressz enforces this limit, it is possible to bypass
it by directly modifying the module parameter as shown below, which then
causes a soft lockup:
echo -1 > /sys/module/sg/parameters/def_reserved_size
exec 4<> /dev/sg0
watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537]
Modules loaded:
CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134,
PREEMPT disabled
Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version
1.16.1-2.fc37 dated 04/01/2014
...
Call Trace:
sg_build_reserve+0x5c/0xa0
sg_add_sfp+0x168/0x270
sg_open+0x16e/0x340
chrdev_open+0xbe/0x230
do_dentry_open+0x175/0x480
vfs_open+0x34/0xf0
do_open+0x265/0x3d0
path_openat+0x110/0x290
do_filp_open+0xc3/0x170
do_sys_openat2+0x71/0xe0
__x64_sys_openat+0x6d/0xa0
do_syscall_64+0x62/0x310
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The fix is to use module_param_cb to validate and reject invalid values
assigned to def_reserved_size.13dCVE-2026-22003—1.1%
——0——CVE-2025-20082—1.1%
——0——CVE-2023-42735—1.1%
——0——CVE-2025-21441—1.1%
——0——CVE-2022-20268—1.1%
——0——CVE-2026-20782—1.1%
——0——CVE-2022-38688—1.1%
——0——CVE-2022-20226—1.1%
——0——CVE-2026-31526—1.1%
——0——