Vulnerabilities exploitable today
356,740in 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,662
New KEV · 24H0
Exploit Today ≥ 701,605
Distribution · last window
- Critical2,546
- High10,622
- Medium6,760
- Low668
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2023-28806—8.6%
——3——CVE-2026-22050—8.6%
——3——CVE-2026-58874.3 MED8.6%
——3Insufficient validation of untrusted input in Downloads in Google Chrome on Windows prior to 147.0.7727.55 allowed a remote attacker to bypass download restrictions via a crafted HTML page. (Chromium security severity: Medium)16dCVE-2026-44497—8.6%
——3——CVE-2025-400067.8 HIG8.6%
——3In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix folio is still mapped when deleted
Migration may be raced with fallocating hole. remove_inode_single_folio
will unmap the folio if the folio is still mapped. However, it's called
without folio lock. If the folio is migrated and the mapped pte has been
converted to migration entry, folio_mapped() returns false, and won't
unmap it. Due to extra refcount held by remove_inode_single_folio,
migration fails, restores migration entry to normal pte, and the folio is
mapped again. As a result, we triggered BUG in filemap_unaccount_folio.
The log is as follows:
BUG: Bad page cache in process hugetlb pfn:156c00
page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00
head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0
aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file"
flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff)
page_type: f4(hugetlb)
page dumped because: still mapped when deleted
CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE
Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
Call Trace:
<TASK>
dump_stack_lvl+0x4f/0x70
filemap_unaccount_folio+0xc4/0x1c0
__filemap_remove_folio+0x38/0x1c0
filemap_remove_folio+0x41/0xd0
remove_inode_hugepages+0x142/0x250
hugetlbfs_fallocate+0x471/0x5a0
vfs_fallocate+0x149/0x380
Hold folio lock before checking if the folio is mapped to avold race with
migration.10dCVE-2024-35342—8.6%
——3——CVE-2025-59093—8.6%
——3——CVE-2023-37224—8.6%
——3——CVE-2024-11071—8.6%
——3——CVE-2025-40604—8.6%
——3——CVE-2022-50709—8.6%
——3——CVE-2025-15543—8.6%
——3——CVE-2023-39374—8.6%
——3——CVE-2025-43406—8.6%
——3——CVE-2026-477345.7 MED8.6%
——3Dulwich is a pure-Python implementation of the Git file formats and protocols. Starting in version 0.1.0 and prior to version 1.2.5, a client with push access could push a tiny crafted thin pack (~174 bytes) whose delta header declares a huge dest_size. When dulwich ingested it via add_thin_pack / apply_delta, it would allocate hundreds of MB of memory based on that attacker-controlled size, with no relationship to the actual bytes received. Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) - for example via dulwich.server functionality, the HTTP smart server, or anything built on ReceivePackHandler - are impacted. The issue is patched in 1.2.5. add_thin_pack now accepts a max_input_size keyword (bytes; 0/None = unlimited, matching git's semantics), and ReceivePackHandler reads receive.maxInputSize from the repository config and passes it through. Wire reads are counted and a PackInputTooLarge exception is raised once the cap is exceeded - equivalent to git index-pack --max-input-size. Users should upgrade to Dulwich 1.2.5 or later and set receive.maxInputSize in their server's repository config to a sane bound for their environment. On unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches and/or run the server under an OS-level memory limit (e.g. ulimit, cgroups/MemoryMax, or a container memory limit) so a malicious push is killed rather than taking down the host.17dCVE-2022-49828—8.6%
——3——CVE-2022-47112—8.6%
——3——CVE-2025-22116—8.6%
——3——CVE-2026-53841—8.6%
——3——CVE-2025-58070—8.6%
——3——CVE-2024-54337—8.6%
——3——CVE-2024-8424—8.6%
——3Improper Privilege Management vulnerability in WatchGuard EPDR, Panda AD360 and Panda Dome on Windows (PSANHost.exe module) allows arbitrary file delete with SYSTEM permissions.2dCVE-2025-2814—8.6%
——3——CVE-2025-505824.8 MED8.6%
——3StudentManage v1.0 was discovered to contain a cross-site scripting (XSS) vulnerability via the Add A New Course module.35dCVE-2025-28864—8.6%
——3——CVE-2025-20311—8.6%
——3——CVE-2024-46779—8.6%
——3——CVE-2026-11379—8.6%
——3——CVE-2023-26097—8.6%
——3——CVE-2024-28099—8.6%
——3——CVE-2025-28859—8.6%
——3——CVE-2021-26950—8.6%
——3——CVE-2020-37042—8.6%
——3——CVE-2025-505844.8 MED8.6%
——3StudentManage v1.0 was discovered to contain a cross-site scripting (XSS) vulnerability via the Add A New Teacher module.35dCVE-2025-28867—8.6%
——3——CVE-2025-59801—8.6%
——3——CVE-2026-02485.9 MED8.6%
——3An improper certificate validation vulnerability in the Prisma Access Agent® for Android and Chrome OS enables an attacker to perform a man-in-the-middle (MitM) attack to intercept VPN traffic. By presenting a certificate for any domain issued by a trusted Certificate Authority, the attacker can capture sensitive device information.
The Prisma Access Agent on macOS, Windows, Linux and iOS are not affected.26dCVE-2023-28084—8.6%
——3——CVE-2025-14739—8.6%
——3——CVE-2021-35075—8.6%
——3——