Vulnerabilidades explotables hoy
367,284en 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,274
- Alto9,335
- Medio5,332
- Bajo522
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2025-33020—1.0%
——0——CVE-2026-23149—1.0%
——0——CVE-2024-49835—1.0%
——0——CVE-2022-20180—0.9%
——0——CVE-2025-29944—1.0%
——0——CVE-2022-20353—1.0%
——0——CVE-2026-20782—1.0%
——0——CVE-2026-531065.5 MED1.0%
——0In the Linux kernel, the following vulnerability has been resolved:
bpf: Do not allow deleting local storage in NMI
Currently, local storage may deadlock when deferring freeing selem or
local storage through kfree_rcu(), call_rcu() or call_rcu_tasks_trace()
in NMI or reentrant. Since deleting selem in NMI is an unlikely use
case, partially mitigate it by returning error when calling from
bpf_xxx_storage_delete() helpers in NMI. Note that, it is still possible
to deadlock through reentrant. A full mitigation requires returning
error when irqs_disabled() is true, which, however is too heavy-handed
for bpf_xxx_storage_delete().
The long-term solution requires _nolock versions of call_rcu. Another
possible solution is to defer the free through irq_work [0], but it
would grow the size of selem, which is non-ideal.
The check is only needed in bpf_selem_unlink(), which is used by helpers
and syscalls. bpf_selem_unlink_nofail() is fine as it is called during
map and owner tear down that never run in NMI or reentrant.
[0] https://lore.kernel.org/bpf/20260205190233.912-1-alexei.starovoitov@gmail.com/39dCVE-2026-118858.4 ALT1.0%
——0IBM PowerVM Hypervisor FW1110.00 through FW1110.20, FW1060.00 through FW1060.71, and FW950.00 through FW950.H1 A carefully crafted OS hypervisor call can cause the PowerVM hypervisor to crash or compromise OS memory integrity.5dCVE-2026-48096—1.0%
——0——CVE-2025-59339—1.0%
——0——CVE-2025-66629—1.0%
——0——CVE-2023-21147—1.0%
——0——CVE-2025-20044—1.0%
——0——CVE-2023-42718—1.0%
——0——CVE-2024-43063—1.0%
——0——CVE-2023-31324—1.0%
——0——CVE-2024-20030—1.0%
——0——CVE-2025-20652—1.0%
——0——CVE-2022-20276—1.0%
——0——CVE-2025-22404—1.0%
——0——CVE-2025-14963—1.0%
——0——CVE-2022-20277—1.0%
——0——CVE-2023-42715—1.0%
——0——CVE-2026-531275.5 MED1.0%
——0In the Linux kernel, the following vulnerability has been resolved:
block: fix zones_cond memory leak on zone revalidation error paths
When blk_revalidate_disk_zones() fails after disk_revalidate_zone_resources()
has allocated args.zones_cond, the memory is leaked because no error path
frees it.39dCVE-2022-20278—1.0%
——0——CVE-2026-585574.8 MED1.0%
——0Design defect vulnerability in Expedition mode. Impact: Successful exploitation of this vulnerability may affect availability.47dCVE-2026-650875.6 MED1.0%
——0NVIDIA NemoClaw contains a vulnerability where an attacker could cause
insufficiently protected credentials . A successful exploit of this vulnerability might lead to information disclosure and data tampering.3dCVE-2026-565675.1 MED1.0%
——0HCL iControl v4.3.0 was affected by Security Misconfiguration vulnerabilities. It involves the public exposure of internal configuration files due to improper web server or application hardening.25dCVE-2024-49844—1.0%
——0——CVE-2026-23197—0.9%
——0——CVE-2026-43045—0.9%
——0——CVE-2026-530795.5 MED0.9%
——0In the Linux kernel, the following vulnerability has been resolved:
net_sched: fix skb memory leak in deferred qdisc drops
When the network stack cleans up the deferred list via qdisc_run_end(),
it operates on the root qdisc. If the root qdisc do not implement the
TCQ_F_DEQUEUE_DROPS flag the packets queue to free are never freed and
gets stranded on the child's local to_free list.
Fix this by making qdisc_dequeue_drop() aware of the root qdisc. It
fetches the root qdisc and check for the TCQ_F_DEQUEUE_DROPS flag. If
the flag is present, the packet is appended directly to the root's
to_free list. Otherwise, drop it directly as it was done before the
optimization was implemented.39dCVE-2026-31369—0.9%
——0——CVE-2026-43348—0.9%
——0——CVE-2024-31333—0.9%
——0——CVE-2022-47341—0.9%
——0——CVE-2026-23211—0.9%
——0——CVE-2026-533195.5 MED0.9%
——0In the Linux kernel, the following vulnerability has been resolved:
blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default()
wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from
wbt_alloc() and wbt_init(). However, both are expected failure paths:
- wbt_alloc() can return NULL under memory pressure (-ENOMEM)
- wbt_init() can fail with -EBUSY if wbt is already registered
syzbot triggers this by injecting memory allocation failures during MTD
partition creation via ioctl(BLKPG), causing a spurious warning.
wbt_init_enable_default() is a best-effort initialization called from
blk_register_queue() with a void return type. Failure simply means the
disk operates without writeback throttling, which is harmless.
Replace WARN_ON_ONCE with plain if-checks, consistent with how
wbt_set_lat() in the same file already handles these failures. Add a
pr_warn() for the wbt_init() failure to retain diagnostic information
without triggering a full stack trace.56dCVE-2026-43478—0.9%
——0——