Vulnerabilidades explotables hoy
367,165en la vista actual
Score único combinando CVSS, membresía KEV y EPSS. Cada CVE con su ficha propia — timeline desde publicación hasta explotación activa.
En catálogo KEV1,685
Nuevos KEV · 24H0
Exploit Today ≥ 701,629
Distribución · última ventana
- Crítico2,263
- Alto9,268
- Medio5,273
- Bajo508
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2023-20816—0.7%
——0——CVE-2023-20639—0.7%
——0——CVE-2026-31756—0.7%
——0——CVE-2023-20707—0.7%
——0——CVE-2023-20786—0.7%
——0——CVE-2026-210623.3 BAJ0.7%
——0Authorization bypass in SemClipboardService prior to SMR Aug-2026 Release 1 allows local attackers to access clipboard data.13dCVE-2026-16526.1 MED0.7%
——0A potential buffer overflow vulnerability was reported in the Lenovo Virtual Bus driver used in Smart Connect that could allow a local authenticated user to corrupt memory and cause a Windows blue screen error.11dCVE-2026-23362—0.7%
——0——CVE-2022-28787—0.7%
——0——CVE-2026-531015.5 MED0.7%
——0In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_sync
roc_abort_sync() can deadlock with roc_work(). roc_work() holds
dev->mt76.mutex, while cancel_work_sync() waits for roc_work()
to finish. If the caller already owns the same mutex, both
sides block and no progress is possible.
This deadlock can occur during station removal when
mt76_sta_state() -> mt76_sta_remove() -> mt7921_mac_sta_remove() ->
mt7921_roc_abort_sync() invokes cancel_work_sync() while
roc_work() is still running and holding dev->mt76.mutex.
This avoids the mutex deadlock and preserves exactly-once
work ownership.41dCVE-2026-24928—0.7%
——0——CVE-2023-20663—0.7%
——0——CVE-2023-21065—0.7%
——0——CVE-2022-20263—0.7%
——0——CVE-2026-530355.5 MED0.7%
——0In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix af_unix iter deadlock
bpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fast
path and the iter prog attempts to update a sockmap. Which ends up spinning
at sock_map_update_elem()'s bh_lock_sock():
WARNING: possible recursive locking detected
test_progs/1393 is trying to acquire lock:
ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: sock_map_update_elem+0xdb/0x1f0
but task is already holding lock:
ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(slock-AF_UNIX);
lock(slock-AF_UNIX);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by test_progs/1393:
#0: ffff88814b59c790 (&p->lock){+.+.}-{4:4}, at: bpf_seq_read+0x59/0x10d0
#1: ffff88811ec25fd8 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: bpf_seq_read+0x42c/0x10d0
#2: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0
#3: ffffffff85a6a7c0 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x51d/0xb00
Call Trace:
dump_stack_lvl+0x5d/0x80
print_deadlock_bug.cold+0xc0/0xce
__lock_acquire+0x130f/0x2590
lock_acquire+0x14e/0x2b0
_raw_spin_lock+0x30/0x40
sock_map_update_elem+0xdb/0x1f0
bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4
bpf_iter_run_prog+0x5b9/0xb00
bpf_iter_unix_seq_show+0x1f7/0x2e0
bpf_seq_read+0x42c/0x10d0
vfs_read+0x171/0xb20
ksys_read+0xff/0x200
do_syscall_64+0x6b/0x3a0
entry_SYSCALL_64_after_hwframe+0x76/0x7e47dCVE-2022-20301—0.7%
——0——CVE-2026-46050—0.7%
——0——CVE-2023-20994—0.7%
——0——CVE-2023-20732—0.7%
——0——CVE-2023-20806—0.7%
——0——CVE-2023-20659—0.7%
——0——CVE-2023-20720—0.7%
——0——CVE-2023-20738—0.7%
——0——CVE-2023-21038—0.7%
——0——CVE-2026-43252—0.7%
——0——CVE-2023-21383—0.7%
——0——CVE-2023-20974—0.7%
——0——CVE-2022-32628—0.7%
——0——CVE-2026-410015.3 MED0.7%
——0Spring Boot's ArtemisEmbeddedConfigurationFactory uses a fixed, static path for the embedded Artemis message broker's data directory when no explicit path is configured. A local attacker on the same host can pre-create this predictable directory or place a symlink before the application starts.
Affected versions:
Spring Boot 4.0.0 through 4.0.6; 3.5.0 through 3.5.14; 3.4.0 through 3.4.16; 3.3.0 through 3.3.19; 2.7.0 through 2.7.33.39dCVE-2026-43147—0.7%
——0——CVE-2026-282626.0 MED0.7%
——0Dell iDRAC Tools, versions prior to 11.4.1.0, contains an Improper Link Resolution Before File Access ('Link Following') vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Information tampering.39dCVE-2026-43382—0.7%
——0——CVE-2022-28786—0.7%
——0——CVE-2022-28785—0.7%
——0——CVE-2023-20805—0.7%
——0——CVE-2024-21950—0.7%
——0——CVE-2026-530375.5 MED0.7%
——0In the Linux kernel, the following vulnerability has been resolved:
HID: usbhid: fix deadlock in hid_post_reset()
You can build a USB device that includes a HID component
and a storage or UAS component. The components can be reset
only together. That means that hid_pre_reset() and hid_post_reset()
are in the block IO error handling. Hence no memory allocation
used in them may do block IO because the IO can deadlock
on the mutex held while resetting a device and calling the
interface drivers.
Use GFP_NOIO for all allocations in them.48dCVE-2023-20662—0.7%
——0——CVE-2025-0083—0.7%
——0——CVE-2022-20312—0.7%
——0——