Vulnerabilities exploitable today
349,195in current view
Single score combining CVSS, KEV membership and EPSS. Every CVE with its own record — timeline from publication to active exploitation.
In KEV catalog1,644
New KEV · 24H0
Exploit Today ≥ 701,579
Distribution · last window
- Critical1,298
- High4,252
- Medium3,575
- Low277
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-20425—0.2%
——0——CVE-2026-20440—0.2%
——0——CVE-2026-20441—0.2%
——0——CVE-2025-27725—0.2%
——0——CVE-2026-20426—0.2%
——0——CVE-2025-31712—0.2%
——0——CVE-2026-20428—0.1%
——0——CVE-2026-41967—0.2%
——0——CVE-2026-530084.7 MED0.2%
——0In the Linux kernel, the following vulnerability has been resolved:
ice: fix race condition in TX timestamp ring cleanup
Fix a race condition between ice_free_tx_tstamp_ring() and ice_tx_map()
that can cause a NULL pointer dereference.
ice_free_tx_tstamp_ring currently clears the ICE_TX_FLAGS_TXTIME flag
after NULLing the tstamp_ring. This could allow a concurrent ice_tx_map
call on another CPU to dereference the tstamp_ring, which could lead to
a NULL pointer dereference.
CPU A:ice_free_tx_tstamp_ring() | CPU B:ice_tx_map()
--------------------------------|---------------------------------
tx_ring->tstamp_ring = NULL |
| ice_is_txtime_cfg() -> true
| tstamp_ring = tx_ring->tstamp_ring
| tstamp_ring->count // NULL deref!
flags &= ~ICE_TX_FLAGS_TXTIME |
Fix by:
1. Reordering ice_free_tx_tstamp_ring() to clear the flag before
NULLing the pointer, with smp_wmb() to ensure proper ordering.
2. Adding smp_rmb() in ice_tx_map() after the flag check to order the
flag read before the pointer read, using READ_ONCE() for the
pointer, and adding a NULL check as a safety net.
3. Converting tx_ring->flags from u8 to DECLARE_BITMAP() and using
atomic bitops (set_bit(), clear_bit(), test_bit()) for all flag
operations throughout the driver:
- ICE_TX_RING_FLAGS_XDP
- ICE_TX_RING_FLAGS_VLAN_L2TAG1
- ICE_TX_RING_FLAGS_VLAN_L2TAG2
- ICE_TX_RING_FLAGS_TXTIME3dCVE-2025-66330—0.2%
——0——CVE-2026-34859—0.2%
——0——CVE-2023-40637—0.2%
——0——CVE-2026-41961—0.2%
——0——CVE-2025-66324—0.2%
——0——CVE-2024-14024—0.2%
——0——CVE-2025-30064—0.2%
——0——CVE-2024-47019—0.2%
——0——CVE-2026-20444—0.2%
——0——CVE-2025-48532—0.2%
——0——CVE-2026-53765—0.2%
——0——CVE-2025-48617—0.2%
——0——CVE-2023-40650—0.2%
——0——CVE-2026-149694.4 MED0.2%
——0A flaw was found in 389-ds-base where the LDBM backend attribute encryption uses a hardcoded static initialization vector for AES-CBC and 3DES-CBC operations, allowing an attacker with privileged filesystem access to detect plaintext equality across encrypted entries by comparing ciphertext blocks.8dCVE-2026-22163—0.2%
——0——CVE-2024-44096—0.2%
——0——CVE-2025-22431—0.2%
——0——CVE-2023-20826—0.2%
——0——CVE-2023-20825—0.2%
——0——CVE-2026-22077—0.2%
——0——CVE-2025-59612—0.2%
——0——CVE-2024-44094—0.2%
——0——CVE-2023-33110—0.2%
——0——CVE-2024-20117—0.2%
——0——CVE-2024-20124—0.2%
——0——CVE-2025-48524—0.2%
——0——CVE-2025-48555—0.2%
——0——CVE-2026-32318—0.2%
——0——CVE-2026-1068—0.2%
——0——CVE-2026-22703—0.2%
——0——CVE-2025-20768—0.2%
——0——