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-2026-43864—0.8%
——0——CVE-2026-43023—0.8%
——0——CVE-2026-0119—0.8%
——0——CVE-2026-32919—0.8%
——0——CVE-2026-28690—0.8%
——0——CVE-2026-641897.8 ALT0.8%
——0In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: fix race between dump and ip_set_list resize
The release path of ip_set_dump_do() and ip_set_dump_done() read
inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw()
of the array pointer. These run from netlink_recvmsg() without the nfnl
mutex and without an RCU read-side critical section.
A concurrent ip_set_create() can grow the array: it publishes the new
array, calls synchronize_net() and then kvfree()s the old one. Since the
dump paths read the array outside any RCU reader, synchronize_net() does
not wait for them and the old array can be freed while they still index
into it, causing a use-after-free.
The dumped set itself stays pinned via set->ref_netlink, so only the
array load needs protecting. Take rcu_read_lock() around it, matching
ip_set_get_byname() and __ip_set_put_byindex().
BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)
Read of size 8 at addr ffff88800b5c4018 by task exploit/150
Call Trace:
...
kasan_report (mm/kasan/report.c:595)
ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)
netlink_dump (net/netlink/af_netlink.c:2325)
netlink_recvmsg (net/netlink/af_netlink.c:1976)
sock_recvmsg (net/socket.c:1159)
__sys_recvfrom (net/socket.c:2315)
...
Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI
KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7]
RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698)
Kernel panic - not syncing: Fatal exception15dCVE-2025-68956—0.8%
——0——CVE-2025-21062—0.8%
——0——CVE-2024-0026—0.8%
——0——CVE-2021-46747—0.8%
——0Insufficient granularity of access control in ASP (AMD Secure Processor) may allow an attacker with an untrusted user space application to map sensitive SMN (System Management Network) apertures leading to a potential escalation of privileges.40dCVE-2025-68955—0.8%
——0——CVE-2026-0034—0.8%
——0——CVE-2025-15320—0.8%
——0——CVE-2022-20322—0.8%
——0——CVE-2026-634247.3 ALT0.8%
——0During an internal security assessment, an improperly protected key was discovered in Lenovo Dock Manager that could allow a local authenticated user to escalate privileges.7dCVE-2026-2103—0.8%
——0——CVE-2023-21192—0.8%
——0——CVE-2026-44279—0.8%
——0——CVE-2021-0401—0.8%
——0——CVE-2025-47387—0.8%
——0——CVE-2026-34126—0.8%
——0——CVE-2023-21394—0.8%
——0——CVE-2026-139054.2 MED0.8%
——0Race in Chrome for iOS in Google Chrome on iOS prior to 150.0.7871.47 allowed a local attacker to obtain potentially sensitive information from process memory via physical access to the device. (Chromium security severity: Medium)61dCVE-2025-48522—0.8%
——0——CVE-2024-49740—0.8%
——0——CVE-2023-20931—0.8%
——0——CVE-2026-20414—0.8%
——0——CVE-2026-4217—0.8%
——0——CVE-2023-20605—0.8%
——0——CVE-2026-618977.8 ALT0.8%
——0An Ubuntu-specific patch to AccountsService before 23.13.9-8ubuntu7 only partially drops privileges before launching language helper scripts. It changes the effective UID/GID to the target user but leaves the real UID as 0 (root). A shell spawned by a helper script inherits ruid=0 and may reset its effective UID to root, enabling local privilege escalation.3dCVE-2026-31798—0.8%
——0——CVE-2017-13315—0.8%
——0——CVE-2023-42687—0.8%
——0——CVE-2025-26424—0.8%
——0——CVE-2020-10843—0.8%
——0——CVE-2025-712217.8 ALT0.8%
——0In the Linux kernel, the following vulnerability has been resolved:
dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue()
Add proper locking in mmp_pdma_residue() to prevent use-after-free when
accessing descriptor list and descriptor contents.
The race occurs when multiple threads call tx_status() while the tasklet
on another CPU is freeing completed descriptors:
CPU 0 CPU 1
----- -----
mmp_pdma_tx_status()
mmp_pdma_residue()
-> NO LOCK held
list_for_each_entry(sw, ..)
DMA interrupt
dma_do_tasklet()
-> spin_lock(&desc_lock)
list_move(sw->node, ...)
spin_unlock(&desc_lock)
| dma_pool_free(sw) <- FREED!
-> access sw->desc <- UAF!
This issue can be reproduced when running dmatest on the same channel with
multiple threads (threads_per_chan > 1).
Fix by protecting the chain_running list iteration and descriptor access
with the chan->desc_lock spinlock.32dCVE-2021-0367—0.8%
——0——CVE-2026-4251—0.8%
——0——CVE-2022-20274—0.8%
——0——CVE-2021-0366—0.8%
——0——