Vulnerabilidades explotables hoy
350,242en 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,647
Nuevos KEV · 24H0
Exploit Today ≥ 701,583
Distribución · última ventana
- Crítico1,426
- Alto4,734
- Medio3,925
- Bajo306
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2023-20956—0.7%
——0——CVE-2025-38241—0.7%
——0——CVE-2025-11791—0.7%
——0——CVE-2025-22422—0.7%
——0——CVE-2026-0024—0.7%
——0——CVE-2023-20973—0.7%
——0——CVE-2024-47030—0.7%
——0——CVE-2023-21160—0.7%
——0——CVE-2022-22263—0.7%
——0——CVE-2023-20974—0.7%
——0——CVE-2025-48640—0.7%
——0——CVE-2021-0874—0.7%
——0——CVE-2025-58287—0.7%
——0——CVE-2023-20731—0.7%
——0——CVE-2026-53850—0.7%
——0——CVE-2026-24917—0.7%
——0——CVE-2023-20676—0.7%
——0——CVE-2025-22430—0.7%
——0——CVE-2023-20677—0.7%
——0——CVE-2026-530207.8 ALT0.7%
——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.6dCVE-2022-47334—0.7%
——0——CVE-2024-45570—0.7%
——0——CVE-2023-20984—0.7%
——0——CVE-2024-39674—0.7%
——0——CVE-2025-48904—0.7%
——0——CVE-2023-21294—0.7%
——0——CVE-2026-5040—0.7%
——0TP-Link Deco M5 v1 uses a weak password hashing mechanism to store user credentials. An attacker who obtains the password hash through system compromise or privileged access could perform brute-force or dictionary attacks.
Successful exploitation may result in disclosure of authentication credentials, enabling unauthorized access to device management functions, depending on the privileges associated with the recovered password. The primary security impact is loss of confidentiality.5dCVE-2023-21025—0.7%
——0——CVE-2026-21025—0.7%
——0——CVE-2021-0875—0.7%
——0——CVE-2026-529795.5 MED0.7%
——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...6dCVE-2024-45563—0.7%
——0——CVE-2026-21033—0.7%
——0——CVE-2023-20648—0.7%
——0——CVE-2026-47328—0.7%
——0——CVE-2023-20621—0.7%
——0——CVE-2023-20649—0.7%
——0——CVE-2025-1243—0.7%
——0——CVE-2024-49740—0.7%
——0——CVE-2026-46194—0.7%
——0——