Vulnerabilidades explotables hoy
367,851en 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,687
Nuevos KEV · 24H0
Exploit Today ≥ 701,629
Distribución · última ventana
- Crítico2,393
- Alto9,631
- Medio5,587
- Bajo548
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2023-53610—3.3%
——1——CVE-2025-5942—3.3%
——1——CVE-2026-23718—3.3%
——1——CVE-2025-14684—3.3%
——1——CVE-2025-65885—3.3%
——1——CVE-2023-53513—3.3%
——1——CVE-2022-20245—3.3%
——1——CVE-2024-35281—3.3%
——1——CVE-2025-27321—3.3%
——1——CVE-2025-434515.5 MED3.3%
——1A permissions issue was addressed by removing the vulnerable code. This issue is fixed in macOS Tahoe 26. An app may be able to access sensitive user data.43dCVE-2025-26499—3.3%
——1——CVE-2021-39690—3.3%
——1——CVE-2021-39678—3.3%
——1——CVE-2025-46367—3.3%
——1——CVE-2024-36315—3.3%
——1——CVE-2022-20056—3.3%
——1——CVE-2025-220128.8 ALT3.3%
——1In the Linux kernel, the following vulnerability has been resolved:
Revert "arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu"
There are reports that the pagetable walker cache coherency is not a
given across the spectrum of SDM845/850 devices, leading to lock-ups
and resets. It works fine on some devices (like the Dragonboard 845c,
but not so much on the Lenovo Yoga C630).
This unfortunately looks like a fluke in firmware development, where
likely somewhere in the vast hypervisor stack, a change to accommodate
for this was only introduced after the initial software release (which
often serves as a baseline for products).
Revert the change to avoid additional guesswork around crashes.
This reverts commit 6b31a9744b8726c69bb0af290f8475a368a4b805.34dCVE-2021-0490—3.3%
——1——CVE-2023-28049—3.3%
——1——CVE-2024-8201—3.3%
——1——CVE-2025-5323—3.3%
——1——CVE-2023-53602—3.3%
——1——CVE-2023-53595—3.3%
——1——CVE-2025-433067.8 ALT3.3%
——1A logic issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. A malicious app may be able to gain root privileges.41dCVE-2026-644697.8 ALT3.3%
——1In the Linux kernel, the following vulnerability has been resolved:
binder: fix UAF in binder_thread_release()
When a thread exits, binder_thread_release() walks its transaction stack
to clear the t->from and t->to_proc that correspond with the exiting
thread. However, a process dying in parallel might attempt to kfree some
of these transactions. And if one of them has no associated t->to_proc,
the t->to_proc->inner_lock will not be acquired.
This means that transaction accesses in binder_thread_release() after
t->to_proc has been cleared might race with binder_free_transaction()
and cause a use-after-free error as reported by KASAN:
==================================================================
BUG: KASAN: slab-use-after-free in binder_thread_release+0x5d0/0x798
Write of size 8 at addr ffff000016627500 by task X/715
CPU: 17 UID: 0 PID: 715 Comm: X Not tainted 7.1.0-rc5-00149-g8fde5d1d47f6 #30 PREEMPT
Hardware name: linux,dummy-virt (DT)
Call trace:
binder_thread_release+0x5d0/0x798
binder_ioctl+0x12c0/0x299c
[...]
Allocated by task 717 on cpu 18 at 67.267803s:
__kasan_kmalloc+0xa0/0xbc
__kmalloc_cache_noprof+0x174/0x444
binder_transaction+0x554/0x8150
binder_thread_write+0xa30/0x4354
binder_ioctl+0x20f0/0x299c
[...]
Freed by task 202 on cpu 18 at 90.416221s:
__kasan_slab_free+0x58/0x80
kfree+0x1a0/0x4a4
binder_free_transaction+0x150/0x294
binder_send_failed_reply+0x398/0x6d8
binder_release_work+0x3e4/0x4ec
binder_deferred_func+0xbd8/0x104c
[...]
==================================================================
In order to avoid this, make sure that binder_free_transaction() reads
the t->to_proc under the transaction lock. This will serialize the
transaction release with the accesses in binder_thread_release(). Plus,
it matches the documented locking rules for @to_proc.16dCVE-2025-14010—3.3%
——1——CVE-2024-47148—3.3%
——1——CVE-2023-53401—3.3%
——1——CVE-2026-31449—3.3%
——1——CVE-2025-12172—3.3%
——1——CVE-2020-27025—3.3%
——1——CVE-2025-20987—3.3%
——1——CVE-2023-53563—3.3%
——1——CVE-2023-53562—3.3%
——1——CVE-2026-608227.8 ALT3.3%
——1Vulnerability in the Oracle Enterprise Manager for Systems Infrastructure product of Oracle Enterprise Manager (component: Agent). Supported versions that are affected are 13.5 and 24.1. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Enterprise Manager for Systems Infrastructure executes to compromise Oracle Enterprise Manager for Systems Infrastructure. Successful attacks of this vulnerability can result in takeover of Oracle Enterprise Manager for Systems Infrastructure. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).12dCVE-2026-641158.8 ALT3.3%
——1In the Linux kernel, the following vulnerability has been resolved:
vsock/vmci: fix UAF when peer resets connection during handshake
vmci_transport_recv_connecting_server() returned err = 0 for a peer
RST in its default switch arm:
err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;
That made vmci_transport_recv_listen() skip vsock_remove_pending(),
leaving the pending socket on the listener's pending_links with
sk_state = TCP_CLOSE while destroy: still dropped the explicit
reference taken before schedule_delayed_work().
One second later vsock_pending_work() observed is_pending=true and
performed full cleanup: vsock_remove_pending() then the two trailing
sock_put(sk) calls -- the first reached refcount 0 and __sk_freed
the socket, and the second wrote into the freed object:
BUG: KASAN: slab-use-after-free in refcount_warn_saturate
Write of size 4 at addr ffff88800b1cac80 by task kworker
Workqueue: events vsock_pending_work
Treat peer RST like any other unexpected packet type (err = -EINVAL).
All destroy: arms now return err < 0, so vmci_transport_recv_listen()
removes pending from pending_links synchronously and
vsock_pending_work() takes the is_pending=false / !rejected branch,
dropping only its own work reference. This also closes the
multi-packet race Sashiko reported on v2: pending is removed from
the list before any subsequent packet can find it.
The pre-existing sk_acceptq_removed() gap on the err < 0 path of
vmci_transport_recv_listen() that Sashiko also noted is not
introduced or changed by this patch.
Tested on lts-6.12.79 with KASAN: 52/100 unpatched -> 0/100 patched.21dCVE-2025-55110—3.3%
——1——CVE-2023-53576—3.3%
——1——CVE-2024-9062—3.3%
——1——CVE-2025-31984—3.3%
——1——