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,269
- Medio5,273
- Bajo508
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-53850—0.6%
——0——CVE-2021-0882—0.6%
——0——CVE-2026-46194—0.6%
——0Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.21dCVE-2023-21135—0.6%
——0——CVE-2023-21025—0.6%
——0——CVE-2026-204746.0 MED0.6%
——0In display, there is a possible escalation of privilege due to a race condition. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS11019183; Issue ID: MSV-7758.12dCVE-2021-0879—0.6%
——0——CVE-2022-48236—0.6%
——0——CVE-2023-21014—0.6%
——0——CVE-2016-11044—0.6%
——0——CVE-2025-36927—0.6%
——0——CVE-2023-21039—0.6%
——0——CVE-2023-20813—0.6%
——0——CVE-2026-529795.5 MED0.6%
——0In the Linux kernel, the following vulnerability has been resolved:
net: psp: check for device unregister when creating assoc
psp_assoc_device_get_locked() obtains a psp_dev reference via
psp_dev_get_for_sock() (which uses psp_dev_tryget() under RCU);
it then acquires psd->lock and drops the reference. Before
the lock is taken, psp_dev_unregister() can run to completion:
take psd->lock, clear out state, unlock, drop the registration
reference.
The expectation is that the lock prevents device unregistration,
but much like with netdevs special care has to be taken when
"upgrading" a reference to a locked device. Add the missing
check if device is still alive. psp_dev_is_registered() exists
already but had no callers, which makes me wonder if I either
forgot to add this or lost the check during refactoring...48dCVE-2023-20644—0.6%
——0——CVE-2026-21025—0.6%
——0——CVE-2023-20748—0.6%
——0——CVE-2026-117423.6 BAJ0.6%
——0The kernel queue helper z_queue_node_peek() in kernel/queue.c dereferences a node taken from a queue's data_q list, reading the node's flag byte and, for items enqueued via k_queue_alloc_append/alloc_prepend, the data pointer of an internally allocated alloc_node struct. The implementations of z_impl_k_queue_peek_head() and z_impl_k_queue_peek_tail() performed this read-and-dereference without holding the queue's spinlock, while every other accessor of the same list — including k_queue_get(), which unlinks a node and k_free()s its backing alloc_node — operates under that lock.
Because peek was unsynchronized, a concurrent k_queue_get() on the same queue (on an SMP build, or under preemption/ISR concurrency) can free the node between the moment peek obtains the node pointer and the moment it dereferences it. The peek then reads flag bits and a data pointer out of freed, potentially re-allocated heap memory and returns a stale or dangling pointer to its caller. k_fifo and k_lifo are thin wrappers over k_queue, so this affects buffer queues used throughout the net_buf, Bluetooth, USB, and networking subsystems; the peek operations are also system calls reachable from CONFIG_USERSPACE threads.
The consequences are a use-after-free read that can leak stale heap contents (one pointer word) and, when the returned dangling pointer is subsequently consumed as a live buffer, a dereference that can crash the system or corrupt memory. Exploitation requires winning a small race window with local access (e.g. a userspace process racing k_queue_peek_* against k_queue_get on a shared queue, or two CPUs), so practical impact is bounded and of low severity.
The fix wraps both peek implementations with k_spin_lock/k_spin_unlock on the queue lock, making the read-and-dereference atomic with respect to the concurrent unlink-and-free and bringing peek into line with the rest of the queue's locking discipline.5dCVE-2021-0880—0.6%
——0——CVE-2023-20679—0.6%
——0——CVE-2025-1243—0.6%
——0——CVE-2023-20651—0.6%
——0——CVE-2024-33043—0.6%
——0——CVE-2023-21013—0.6%
——0——CVE-2023-23349—0.6%
——0——CVE-2023-40120—0.6%
——0——CVE-2023-20742—0.6%
——0——CVE-2026-530207.8 ALT0.6%
——0In the Linux kernel, the following vulnerability has been resolved:
um: Fix potential race condition in TLB sync
During the TLB sync, we need to traverse and modify the page table,
so we should hold the page table lock. Since full SMP support for
threads within the same process is still missing, let's disable the
split page table lock for simplicity.47dCVE-2025-48620—0.6%
——0——CVE-2021-0483—0.6%
——0——CVE-2025-12708—0.6%
——0——CVE-2026-210775.5 MED0.6%
——0Incorrect authorization in Samsung Health prior to version 7.0.0 allows local attackers to access sensitive information.12dCVE-2023-20984—0.6%
——0——CVE-2026-54327—0.6%
——0——CVE-2026-21022—0.6%
——0——CVE-2021-0565—0.6%
——0——CVE-2025-48583—0.6%
——0——CVE-2026-0032—0.6%
——0——CVE-2026-687443.3 BAJ0.6%
——0A flaw was found in SSSD. The sss_nss_protocol_fill_initgr() function in the NSS responder pre-allocates reply space for all group entries but does not shrink the packet when groups are skipped, causing uninitialized heap bytes to be transmitted to the client. A local attacker can exploit this to disclose cached directory data and heap layout information from the sssd_nss process.13dCVE-2026-53809—0.6%
——0——