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-2024-56694—6.3%
——2——CVE-2024-39296—6.3%
——2——CVE-2022-41209—6.3%
——2——CVE-2026-659146.1 MED6.3%
——2DOMPurify before 3.3.2 contains a mutation-XSS vulnerability when sanitized HTML is reinserted into special parsing contexts using innerHTML with wrappers like script, xmp, iframe, noembed, noframes, or noscript. Attackers can craft payloads with closing sequences that break out of the wrapper context during reparsing, reactivating dangerous markup with event handlers to execute JavaScript.5dCVE-2021-38938—6.3%
——2——CVE-2026-28877—6.3%
——2——CVE-2026-32692—6.2%
——2——CVE-2018-16498—6.2%
——2——CVE-2019-25590—6.2%
——2——CVE-2025-68802—6.2%
——2——CVE-2026-64021—6.2%
——2In the Linux kernel, the following vulnerability has been resolved:
drm/xe/oa: Fix exec_queue leak on width check in stream open
In xe_oa_stream_open_ioctl(), when param.exec_q->width > 1 the
function returns -EOPNOTSUPP directly, skipping the existing
err_exec_q cleanup path. The exec_queue reference obtained by
xe_exec_queue_lookup() is leaked.
The exec queue holds a reference on the xe_file, which is only
dropped during queue teardown. The leaked lookup ref is not on
the file's exec_queue xarray, so file close cannot release it.
This keeps both the exec queue and the file private state pinned
indefinitely.
Jump to err_exec_q instead of returning directly so the reference
is released.
(cherry picked from commit 339fa0be9e4a5d69fa47e91f4a36574224fb478f)3dCVE-2026-63983—6.2%
——2In the Linux kernel, the following vulnerability has been resolved:
net/sched: fix packet loop on netem when duplicate is on
When netem duplicates a packet it re-enqueues the copy at the root qdisc.
If another netem sits in the tree the copy can be duplicated
again, recursing until the stack or memory is exhausted.
The original duplication guard temporarily zeroed q->duplicate around
the re-enqueue, but that does not cover all cases because it is
per-qdisc state shared across all concurrent enqueue paths
and is not safe without additional locking.
Use the skb tc_depth field introduced in an earlier patch:
- increment it on the duplicate before re-enqueue
- skip duplication for any skb whose tc_depth is already non-zero.
This marks the packet itself rather than mutating qdisc state,
therefore it is safe regardless of tree topology or concurrency.3dCVE-2024-30149—6.2%
——2——CVE-2024-32900—6.2%
——2——CVE-2026-366154.3 MED6.2%
——2Mercusys AC12G (EU) V1 with firmware AC12G(EU)_V1_200909 exposes an undocumented /agileconfigreset endpoint that returns internal buffer contents to unauthenticated attackers on the adjacent network.11dCVE-2026-483487.7 HIG6.2%
——2Animate is affected by an Incorrect Authorization vulnerability that could result in arbitrary code execution in the context of the current user. Exploit depends on conditions beyond the attacker's control. Exploitation of this issue requires user interaction in that a victim must open a malicious file. Scope is changed.17dCVE-2026-64426—6.2%
——2In the Linux kernel, the following vulnerability has been resolved:
io_uring/nop: fix file reference leak with IOSQE_FIXED_FILE
NOP file-acquisition support choses between a fixed (registered) file and
a normal fget()'d file based on its own IORING_NOP_FIXED_FILE flag in
sqe->nop_flags. However, a request's REQ_F_FIXED_FILE is set
independently from the generic IOSQE_FIXED_FILE sqe flag during request
init, before the issue handler runs.
If a NOP is submitted with IOSQE_FIXED_FILE set (so REQ_F_FIXED_FILE is
set) but without IORING_NOP_FIXED_FILE, io_nop() takes the normal path
and grabs a real reference via io_file_get_normal(). On completion,
io_put_file() only drops the reference when REQ_F_FIXED_FILE is clear,
so the fget()'d file is never released and leaks:
BUG: memory leak
unreferenced object 0xffff88800f42c240 (size 176):
kmem_cache_alloc_noprof+0x358/0x440
alloc_empty_file+0x57/0x180
path_openat+0x44/0x1e50
do_file_open+0x121/0x200
do_sys_openat2+0xa7/0x150
__x64_sys_openat+0x82/0xf0
Decide between fixed and normal file acquisition from REQ_F_FIXED_FILE,
the same way io_assign_file() does for every other opcode, and fold
IORING_NOP_FIXED_FILE into REQ_F_FIXED_FILE at prep time.9dCVE-2026-23055—6.2%
——2——CVE-2026-576846.5 MED6.2%
——2Contributor Cross Site Scripting (XSS) in TheFox <= 3.9.70 versions.32dCVE-2025-386537.8 HIG6.2%
——2In the Linux kernel, the following vulnerability has been resolved:
proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al
Check pde->proc_ops->proc_lseek directly may cause UAF in rmmod scenario.
It's a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF in
proc_get_inode()"). Followed by AI Viro's suggestion, fix it in same
manner.4dCVE-2024-3655—6.2%
——2——CVE-2026-64022—6.2%
——2In the Linux kernel, the following vulnerability has been resolved:
gpio: aggregator: remove the software node when deactivating the aggregator
The dynamic software node we create for the aggregator platform device
when using configfs is leaked when the device is deactivated. Destroy it
as the last step in the tear-down path.3dCVE-2026-59114.3 MED6.2%
——2Policy bypass in ServiceWorkers in Google Chrome prior to 147.0.7727.55 allowed a remote attacker to bypass content security policy via a crafted HTML page. (Chromium security severity: Low)10dCVE-2026-483097.8 HIG6.2%
——2Audition is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.19dCVE-2026-63998—6.2%
——2In the Linux kernel, the following vulnerability has been resolved:
ethtool: module: call ethnl_ops_complete() on module flash errors
When validate() fails we are skipping over ethnl_ops_complete()
even tho we already called ethnl_ops_begin().3dCVE-2025-59800—6.2%
——2——CVE-2023-28047—6.2%
——2——CVE-2022-50115—6.2%
——2——CVE-2026-26272—6.2%
——2——CVE-2025-54256—6.2%
——2——CVE-2026-366024.3 MED6.2%
——2Mercusys AC12G (EU) V1 router with firmware AC12G(EU)_V1_200909 discloses kernel memory layout via the UPnP GetStatusInfo action. An unauthenticated attacker on the adjacent network can obtain a raw MIPS KSEG0 kernel pointer, revealing kernel memory layout and aiding further exploitation.11dCVE-2026-33797—6.2%
——2——CVE-2026-64145—6.2%
——2In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: fix dma_buffer leak on bus acquire failure
wilc_wlan_firmware_download() allocates dma_buffer with kmalloc() at
the top of the function and uses a 'fail:' label to free it via
kfree(dma_buffer) on error.
All later error paths correctly use 'goto fail' to route through this
cleanup. However, the early failure path after the first acquire_bus()
call uses a bare 'return ret;', which leaks dma_buffer whenever the bus
acquire fails.
Replace the early return with goto fail so the existing cleanup path
runs.
Found via a custom Coccinelle semantic patch hunting for kmalloc'd
locals leaked on early-return error paths in driver firmware-download
code.3dCVE-2026-27589—6.2%
——2——CVE-2025-67544—6.2%
——2——CVE-2026-64212—6.2%
——2In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mld: don't dereference a pointer before NULL checking it
In iwl_mld_remove_link, the link->fw_id is saved at the beginning of the
function so we have it after we freed the link.
But the link pointer can be NULL, and is not checked when the fw_id is
stored.
Fix it by simply freeing the link at the end of the function.
fFixes: 0e66a39f4f0e ("wifi: iwlwifi: fix potential use after free in iwl_mld_remove_link()")3dCVE-2026-64049—6.2%
——2In the Linux kernel, the following vulnerability has been resolved:
drm/msm/adreno: fix userspace-triggered crash on a2xx-a4xx
Before a5xx Adreno driver will not try fetching UBWC params (because
those generations didn't support UBWC anyway), however it's still
possible to query UBWC-related params from the userspace, triggering
possible NULL pointer dereference. Check for UBWC config in
adreno_get_param() and return sane defaults if there is none.
Patchwork: https://patchwork.freedesktop.org/patch/717778/3dCVE-2026-64341—6.2%
——2In the Linux kernel, the following vulnerability has been resolved:
USB: iowarrior: fix use-after-free on disconnect race
mutex_unlock() may access the mutex structure after releasing the lock
and therefore cannot be used to manage lifetime of objects directly
(unlike spinlocks and refcounts). [1][2]
Use a kref to release the driver data to avoid use-after-free in
mutex_unlock() when release() races with disconnect().
[1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic")
[2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most
other sleeping locks, can still use the lock object
after it's unlocked")9dCVE-2023-38558—6.2%
——2——CVE-2026-40200—6.2%
——2——