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,295
- Alto9,356
- Medio5,355
- Bajo528
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2025-52516—2.0%
——1——CVE-2026-23121—2.0%
——1——CVE-2026-150595.5 MED2.0%
——1Local unprivileged users can terminate arbitrary local processes via a systemd-oomd IPC API due to a missing path traversal validation.22dCVE-2021-0439—2.0%
——1——CVE-2026-46235—2.0%
——1——CVE-2026-641835.5 MED2.0%
——1In the Linux kernel, the following vulnerability has been resolved:
efi: Allocate runtime workqueue before ACPI init
Since commit
5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers")
ACPI PRM calls are delegated to a workqueue which runs in a kernel
thread, making it easier to detect and mitigate faulting memory accesses
performed by the firmware.
Rafael reports that such PRM accesses may occur before efisubsys_init()
executes, which is where the workqueue is allocated, leading to NULL
pointer dereferences. Since acpi_init() [which triggers the early PRM
accesses] executes as a subsys_initcall() as well, and has its own
dependencies that may be sensitive to initcall ordering, deferring
acpi_init() is not an option.
So instead, split off the workqueue allocation into its own postcore
initcall, as this is the only missing piece to allow EFI runtime calls
to be made. This ensures that EFI runtime call (including PRM calls) are
accessible to all code running at subsys_initcall() level.20dCVE-2026-40144—2.0%
——1A memory-corruption vulnerability exists in a kernel-mode component of BeyondTrust Endpoint Privilege Management (Windows deployments) prior to version 26.1.2. Insufficient validation of input processed by the component may result in memory being accessed outside its intended bounds.15dCVE-2026-462717.8 ALT2.0%
——1In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: do WoW offloads only on primary link
In case of multi-link connection, WCN7850 firmware crashes due to WoW
offloads enabled on both primary and secondary links.
Change to do it only on primary link to fix it.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-140dCVE-2026-531187.8 ALT2.0%
——1In the Linux kernel, the following vulnerability has been resolved:
vdpa: use generic driver_override infrastructure
When a driver is probed through __driver_attach(), the bus' match()
callback is called without the device lock held, thus accessing the
driver_override field without a lock, which can cause a UAF.
Fix this by using the driver-core driver_override infrastructure taking
care of proper locking internally.
Note that calling match() from __driver_attach() without the device lock
held is intentional. [1]39dCVE-2018-5849—1.9%
——1——CVE-2021-0442—2.0%
——1——CVE-2025-38388—2.0%
——1——CVE-2025-64701—2.0%
——1——CVE-2024-41750—2.0%
——1——CVE-2025-12793—2.0%
——1——CVE-2026-106816.5 MED2.0%
——1In Zephyr's userspace dynamic-objects subsystem, thread_idx_alloc() in kernel/userspace/userspace.c allocated a new thread permission index from the global _thread_idx_map[] bitmap without holding lists_lock.
On SMP systems, two user-mode threads invoking the k_object_alloc(K_OBJ_THREAD) syscall concurrently can both observe the same low free bit, perform the same non-atomic RMW to clear it, and return the identical tidx.
The two newly created K_OBJ_THREAD objects are then assigned the same thread_id, so the two user threads alias a single bit position in every kernel object's perms[] bitfield: any subsequent grant of access on a kernel object to one thread is implicitly a grant to the other, defeating userspace ACL isolation. A secondary lost-update window between the unlocked &=~BIT() in alloc and the locked |= BIT() in thread_idx_free() can also leak entries from the thread-index pool.
The defect is reachable from any user-mode thread via the unrestricted __syscall k_object_alloc and is gated on CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, and CONFIG_SMP. The flaw was introduced when the per-thread permission index was added in 2018 and is present in every release up to and including v4.4.0. Fixed by holding lists_lock across the bitmap RMW and the permissions clear (and inlining the obj_list traversal that previously took the lock itself).20dCVE-2026-20994—2.0%
——1——CVE-2026-7280—2.0%
——1——CVE-2023-53565—2.0%
——1——CVE-2025-11964—2.0%
——1——CVE-2025-10491—2.0%
——1——CVE-2022-3702—2.0%
——1——CVE-2026-42146—2.0%
——1——CVE-2022-33217—2.0%
——1——CVE-2023-53574—2.0%
——1——CVE-2025-39959—2.0%
——1——CVE-2026-43461—2.0%
——1——CVE-2025-39892—2.0%
——1——CVE-2026-43265—2.0%
——1——CVE-2022-498847.8 ALT2.0%
——1In the Linux kernel, the following vulnerability has been resolved:
KVM: Initialize gfn_to_pfn_cache locks in dedicated helper
Move the gfn_to_pfn_cache lock initialization to another helper and
call the new helper during VM/vCPU creation. There are race
conditions possible due to kvm_gfn_to_pfn_cache_init()'s
ability to re-initialize the cache's locks.
For example: a race between ioctl(KVM_XEN_HVM_EVTCHN_SEND) and
kvm_gfn_to_pfn_cache_init() leads to a corrupted shinfo gpc lock.
(thread 1) | (thread 2)
|
kvm_xen_set_evtchn_fast |
read_lock_irqsave(&gpc->lock, ...) |
| kvm_gfn_to_pfn_cache_init
| rwlock_init(&gpc->lock)
read_unlock_irqrestore(&gpc->lock, ...) |
Rename "cache_init" and "cache_destroy" to activate+deactivate to
avoid implying that the cache really is destroyed/freed.
Note, there more races in the newly named kvm_gpc_activate() that will
be addressed separately.
[sean: call out that this is a bug fix]28dCVE-2025-38268—2.0%
——1——CVE-2026-58089—2.0%
——1——CVE-2025-21000—2.0%
——1——CVE-2021-0303—1.9%
——1——CVE-2026-97355.5 MED2.0%
——1MongoDB server may log authentication parameters, including credentials, to the server log during SASL authentication. When connection health metric logging is enabled, the full authentication parameters are written to the log without redaction.40dCVE-2025-62794—2.0%
——1——CVE-2025-20997—2.0%
——1——CVE-2023-41833—2.0%
——1——CVE-2023-32448—2.0%
——1——CVE-2026-46236—2.0%
——1——