Vulnerabilities exploitable today
349,429in 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,647
New KEV · 24H0
Exploit Today ≥ 701,582
Distribution · last window
- Critical1,327
- High4,319
- Medium3,691
- Low289
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2022-32634—0.7%
——0——CVE-2023-20626—0.7%
——0——CVE-2023-20657—0.7%
——0——CVE-2026-534107.0 HIG0.7%
——0A time-of-check to time-of-use (TOCTOU) race condition in the installation and uninstallation process of certain Zoom Clients for Windows could allow an authenticated local user to escalate privileges.12hCVE-2023-20664—0.7%
——0——CVE-2025-40753—0.7%
——0——CVE-2026-24199—0.7%
——0——CVE-2022-20349—0.7%
——0——CVE-2023-20608—0.7%
——0——CVE-2023-21187—0.7%
——0——CVE-2026-139054.2 MED0.7%
——0Race in Chrome for iOS in Google Chrome on iOS prior to 150.0.7871.47 allowed a local attacker to obtain potentially sensitive information from process memory via physical access to the device. (Chromium security severity: Medium)16dCVE-2023-21324—0.7%
——0——CVE-2026-452596.5 MED0.7%
——0sigqueue(2) was marked as permitted in capability mode with the introduction of Capsicum in 2011, but the implementation of kern_sigqueue did not include a capability mode check restricting signal delivery to the calling process's own PID.
A process in capability mode can use sigqueue(2) to send signals to any process it could signal following standard Unix permissions, bypassing the Capsicum sandbox restriction. A compromised sandboxed process could interfere with other processes, for example by sending SIGKILL or SIGSTOP. This could be any process running as the same user, or any process, for a superuser sandboxed process.17dCVE-2023-20751—0.7%
——0——CVE-2026-46692—0.7%
——0——CVE-2025-26464—0.7%
——0——CVE-2025-14599—0.7%
——0——CVE-2022-20323—0.7%
——0——CVE-2026-9759—0.7%
——0——CVE-2022-48241—0.7%
——0——CVE-2026-7351—0.7%
——0——CVE-2023-21200—0.7%
——0——CVE-2023-20696—0.7%
——0——CVE-2024-39428—0.7%
——0——CVE-2023-21198—0.7%
——0——CVE-2026-529597.8 HIG0.7%
——0In the Linux kernel, the following vulnerability has been resolved:
virt: sev-guest: Do not use host-controlled page order in cleanup path
When issuing an extended guest request (SVM_VMGEXIT_EXT_GUEST_REQUEST),
get_ext_report() allocates a buffer to retrieve a certificate blob from the
host, keeping track of its size in report_req->certs_len.
However, the host may return SNP_GUEST_VMM_ERR_INVALID_LEN, indicating
an invalid buffer size, as well as the expected length of such buffer.
get_ext_report() subsequently updates report_req->certs_len with the
host-controlled value, and cleans up the buffer by computing a page order
from such value. This is incorrect, as the host-provided length may not
match the page order of the original allocation, potentially resulting
in corruption in the page allocator.
Fix this by using alloc_pages_exact() instead, and reusing @npages to
compute the size passed to free_pages_exact(). For consistency, also
use @npages to compute the size when allocating the pages, even though
this last change has no functional effect.4dCVE-2026-53809—0.7%
——0——CVE-2023-20725—0.7%
——0——CVE-2023-20995—0.7%
——0——CVE-2022-32625—0.7%
——0——CVE-2022-32624—0.7%
——0——CVE-2024-29754—0.7%
——0——CVE-2024-29753—0.7%
——0——CVE-2024-29743—0.7%
——0——CVE-2022-48231—0.7%
——0——CVE-2024-22007—0.7%
——0——CVE-2023-21176—0.7%
——0——CVE-2021-0529—0.7%
——0——CVE-2025-0079—0.7%
——0——CVE-2023-42742—0.7%
——0——