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,274
- Bajo508
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2025-399417.8 ALT0.6%
——0In the Linux kernel, the following vulnerability has been resolved:
zram: fix slot write race condition
Parallel concurrent writes to the same zram index result in leaked
zsmalloc handles. Schematically we can have something like this:
CPU0 CPU1
zram_slot_lock()
zs_free(handle)
zram_slot_lock()
zram_slot_lock()
zs_free(handle)
zram_slot_lock()
compress compress
handle = zs_malloc() handle = zs_malloc()
zram_slot_lock
zram_set_handle(handle)
zram_slot_lock
zram_slot_lock
zram_set_handle(handle)
zram_slot_lock
Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done
too early. In fact, we need to reset zram entry right before we set its
new handle, all under the same slot lock scope.32dCVE-2023-21271—0.6%
——0——CVE-2025-71111—0.6%
——0——CVE-2023-21381—0.6%
——0——CVE-2023-20681—0.6%
——0——CVE-2026-0296—0.6%
——0Improper certificate validation vulnerabilities in Palo Alto Networks GlobalProtect™ app enable an unauthenticated attacker with man-in-the-middle (MitM) access to intercept and modify application communications. VPN tunnel traffic is not impacted.
The GlobalProtect app on iOS, Android, and Chrome OS is not affected.13dCVE-2025-32349—0.6%
——0——CVE-2022-32624—0.6%
——0——CVE-2023-20658—0.6%
——0——CVE-2023-20725—0.6%
——0——CVE-2023-20621—0.6%
——0——CVE-2022-32625—0.6%
——0——CVE-2023-42744—0.6%
——0——CVE-2021-39735—0.6%
——0——CVE-2023-20998—0.6%
——0——CVE-2023-21155—0.6%
——0——CVE-2023-32839—0.6%
——0——CVE-2023-21152—0.6%
——0——CVE-2025-596095.5 MED0.6%
——0Information Disclosure when processing advertisement frames with malformed MBSSID elements of insufficient length.40dCVE-2021-0934—0.6%
——0——CVE-2026-21015—0.6%
——0——CVE-2018-9371—0.6%
——0——CVE-2022-38674—0.6%
——0——CVE-2026-179843.3 BAJ0.6%
——0Inappropriate implementation in Browser in Google Chrome on Android prior to 151.0.7922.72 allowed a local attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low)28dCVE-2026-345275.3 MED0.6%
——0Sandboxie-Plus is an open source sandbox-based isolation software for Windows. In versions 1.17.2 and earlier, SbieIniServer::HashPassword converts a SHA-1 digest to hexadecimal incorrectly. The high nibble of each byte is shifted right by 8 instead of 4, which always produces zero for an 8-bit value. As a result, the stored EditPassword hash only preserves the low nibble of each digest byte, reducing the effective entropy from 160 bits to 80 bits. This is layered on top of an unsalted SHA-1 scheme. The reduced entropy makes leaked or backed-up password hashes materially easier to brute-force.
This issue has been fixed in version 1.17.3.38dCVE-2023-21145—0.6%
——0——CVE-2023-20697—0.5%
——0——CVE-2023-20698—0.5%
——0——CVE-2025-47399—0.6%
——0——CVE-2026-20993—0.6%
——0——CVE-2026-28716—0.6%
——0——CVE-2026-43275—0.6%
——0——CVE-2024-43108—0.6%
——0——CVE-2022-47351—0.6%
——0——CVE-2026-585627.3 ALT0.6%
——0Dell Command Update (DCU), versions prior to 5.7.1, contain a Missing Authorization vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Unauthorized access.10dCVE-2023-23588—0.6%
——0——CVE-2026-32803—0.6%
——0——CVE-2022-20230—0.6%
——0——CVE-2025-710795.5 MED0.6%
——0In the Linux kernel, the following vulnerability has been resolved:
net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write
A deadlock can occur between nfc_unregister_device() and rfkill_fop_write()
due to lock ordering inversion between device_lock and rfkill_global_mutex.
The problematic lock order is:
Thread A (rfkill_fop_write):
rfkill_fop_write()
mutex_lock(&rfkill_global_mutex)
rfkill_set_block()
nfc_rfkill_set_block()
nfc_dev_down()
device_lock(&dev->dev) <- waits for device_lock
Thread B (nfc_unregister_device):
nfc_unregister_device()
device_lock(&dev->dev)
rfkill_unregister()
mutex_lock(&rfkill_global_mutex) <- waits for rfkill_global_mutex
This creates a classic ABBA deadlock scenario.
Fix this by moving rfkill_unregister() and rfkill_destroy() outside the
device_lock critical section. Store the rfkill pointer in a local variable
before releasing the lock, then call rfkill_unregister() after releasing
device_lock.
This change is safe because rfkill_fop_write() holds rfkill_global_mutex
while calling the rfkill callbacks, and rfkill_unregister() also acquires
rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will
wait for any ongoing callback to complete before proceeding, and
device_del() is only called after rfkill_unregister() returns, preventing
any use-after-free.
The similar lock ordering in nfc_register_device() (device_lock ->
rfkill_global_mutex via rfkill_register) is safe because during
registration the device is not yet in rfkill_list, so no concurrent
rfkill operations can occur on this device.48dCVE-2025-14575—0.6%
——0An Uncontrolled Search Path Element vulnerability in the OpenSSL TLS backend of Qt Network (qtbase) in Qt Qt Framework (Unix) allows a local attacker to load a rogue CA certificate as a trusted system authority via a crafted certificate file placed in the application's working directory.33d