Vulnerabilities exploitable today
374,209in 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,710
New KEV · 24H0
Exploit Today ≥ 701,645
Distribution · last window
- Critical2,328
- High8,275
- Medium6,438
- Low714
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2024-4929—26.8%
——8——CVE-2024-37254—26.8%
——8——CVE-2024-12826—26.8%
——8——CVE-2022-29489—26.8%
——8——CVE-2026-191528.3 HIG26.8%
——8Insufficient policy enforcement in Navigation in Google Chrome prior to 151.0.7922.109 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)39dCVE-2026-26311—26.8%
——8——CVE-2024-32517—26.8%
——8——CVE-2023-34461—26.8%
——8——CVE-2024-32148—26.8%
——8——CVE-2023-35648—26.8%
——8——CVE-2025-1262—26.8%
——8——CVE-2026-26710—26.8%
——8——CVE-2026-528787.5 HIG26.8%
——8Klever-Go is the Go implementation of the Klever blockchain protocol. Versions 1.7.14 through 1.7.17 are vulnerable to a nil-pointer panic triggered by a protobuf Transaction whose embedded RawData sub-message is omitted. This omission causes RawData to decode to nil. Every transaction gossiped on the Klever-Go P2P network is decoded and validated synchronously inside the libp2p pubsub topic-validator callback, where txVersionChecker.CheckTxVersion dereferences tx.RawData.Version with no nil check. Because the libp2p pubsub callback, the underlying go-libp2p-pubsub validation worker, and Klever's own network/p2p layer install no recover(), the panic propagates and crashes the entire node process. The attacker payload is a 3-byte protobuf message; no validator key, stake, funds, or on-chain account is required, and delivery aimed at enough of the BLS validator set can halt block production, resulting in a chain halt. This issue has been fixed in version 1.7.18.6dCVE-2024-32520—26.8%
——8——CVE-2025-0506—26.8%
——8——CVE-2008-2324—26.8%
——8——CVE-2025-55690—26.8%
——8——CVE-2019-10364—26.8%
——8——CVE-2008-0662—26.8%
——8——CVE-2020-0546—26.8%
——8——CVE-2012-0105—26.8%
——8——CVE-2024-2214—26.8%
——8——CVE-2023-44109—26.8%
——8——CVE-2026-32053—26.8%
——8——CVE-2024-43134—26.8%
——8——CVE-2011-0796—26.8%
——8——CVE-2026-54245—26.8%
——8Fleet is an open-source device management platform built on osquery. In versions prior to 4.86.2, the Okta conditional access integration in Fleet Premium is vulnerable to SQL injection through a host-supplied value that is used in a database query without proper parameterization, allowing an attacker who controls a single enrolled host to read or modify arbitrary data in the Fleet database. The value is reported by the host's own agent and stored verbatim, then used on an unauthenticated request path that supports the conditional access integration, so any party controlling one enrolled host, the lowest-privilege position in the product, can influence the query. By disclosing arbitrary database contents an attacker can extract stored session tokens and replay them to act as a global administrator, and on a managed fleet that administrator access enables running scripts on enrolled hosts, leading to remote code execution. The issue requires Fleet Premium with the Okta conditional access integration enabled and does not affect instances where it is not configured. This issue is fixed in version 4.86.2.20dCVE-2010-2522—26.8%
——8——CVE-2023-52376—26.8%
——8——CVE-2025-5407—26.8%
——8——CVE-2023-44093—26.8%
——8——CVE-2022-4554—26.8%
——8——CVE-2026-557357.5 HIG26.8%
——8Improper Verification of Cryptographic Signature in ueberauth guardian allows an unauthenticated attacker to revoke a victim's session with a forged token.
Guardian.revoke/3 in lib/guardian.ex decodes the supplied token with peek/1, which performs no signature verification (it only base64-decodes the JWT header and payload). The resulting unverified claims are forwarded directly to the configured token module's revoke callback and the implementation's on_revoke callback, a state-mutating sink. The sibling operations refresh/2 and exchange/4 both call decode_and_verify first, so the signature is checked before anything acts on the claims; revoke/3 is the only state-mutating path that acts on claims without verifying the signature.
An attacker who knows or guesses a victim's identifying claim values (jti, sub) can forge a JWT carrying those claims, sign it with an arbitrary key, and submit it to any endpoint that funnels a caller-supplied token into Guardian.revoke/3 (the standard logout / session-revocation pattern). When the token module mutates state keyed by the claims (whitelist deletion or blacklist insertion, for example a GuardianDb-style store), the victim's legitimate session is evicted. This is an unauthenticated session-revocation denial of service; the attacker never needs the signing secret.
This issue affects guardian: from 1.0.0 before 2.4.1.41dCVE-2019-14608—26.8%
——8——CVE-2024-37218—26.8%
——8——CVE-2022-44349—26.8%
——8——CVE-2020-0530—26.8%
——8——CVE-2019-11120—26.8%
——8——CVE-2019-14599—26.8%
——8——CVE-2024-32828—26.8%
——8——