Vulnerabilities exploitable today
356,659in 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,532
- High10,669
- Medium6,832
- Low683
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2024-33582—7.9%
——2——CVE-2025-32728—7.9%
——2——CVE-2023-22443—7.9%
——2——CVE-2023-25493—7.9%
——2——CVE-2024-33580—7.9%
——2——CVE-2024-580987.8 HIG7.9%
——2In the Linux kernel, the following vulnerability has been resolved:
bpf: track changes_pkt_data property for global functions
When processing calls to certain helpers, verifier invalidates all
packet pointers in a current state. For example, consider the
following program:
__attribute__((__noinline__))
long skb_pull_data(struct __sk_buff *sk, __u32 len)
{
return bpf_skb_pull_data(sk, len);
}
SEC("tc")
int test_invalidate_checks(struct __sk_buff *sk)
{
int *p = (void *)(long)sk->data;
if ((void *)(p + 1) > (void *)(long)sk->data_end) return TCX_DROP;
skb_pull_data(sk, 0);
*p = 42;
return TCX_PASS;
}
After a call to bpf_skb_pull_data() the pointer 'p' can't be used
safely. See function filter.c:bpf_helper_changes_pkt_data() for a list
of such helpers.
At the moment verifier invalidates packet pointers when processing
helper function calls, and does not traverse global sub-programs when
processing calls to global sub-programs. This means that calls to
helpers done from global sub-programs do not invalidate pointers in
the caller state. E.g. the program above is unsafe, but is not
rejected by verifier.
This commit fixes the omission by computing field
bpf_subprog_info->changes_pkt_data for each sub-program before main
verification pass.
changes_pkt_data should be set if:
- subprogram calls helper for which bpf_helper_changes_pkt_data
returns true;
- subprogram calls a global function,
for which bpf_subprog_info->changes_pkt_data should be set.
The verifier.c:check_cfg() pass is modified to compute this
information. The commit relies on depth first instruction traversal
done by check_cfg() and absence of recursive function calls:
- check_cfg() would eventually visit every call to subprogram S in a
state when S is fully explored;
- when S is fully explored:
- every direct helper call within S is explored
(and thus changes_pkt_data is set if needed);
- every call to subprogram S1 called by S was visited with S1 fully
explored (and thus S inherits changes_pkt_data from S1).
The downside of such approach is that dead code elimination is not
taken into account: if a helper call inside global function is dead
because of current configuration, verifier would conservatively assume
that the call occurs for the purpose of the changes_pkt_data
computation.4dCVE-2018-6693—7.9%
——2——CVE-2025-52490—7.9%
——2——CVE-2025-60936—7.9%
——2——CVE-2026-23810—7.9%
——2——CVE-2018-11300—7.9%
——2——CVE-2024-55642—7.9%
——2——CVE-2025-68296—7.9%
——2——CVE-2026-112644.3 MED7.9%
——2Policy bypass in Content Security Policy in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to bypass content security policy via a crafted HTML page. (Chromium security severity: Low)16dCVE-2024-55929—7.9%
——2——CVE-2022-2332—7.9%
——2——CVE-2025-12434—7.9%
——2——CVE-2026-5942—7.9%
——2——CVE-2022-49741—7.9%
——2——CVE-2025-21980—7.9%
——2——CVE-2026-54029—7.9%
——2——CVE-2022-35276—7.9%
——2——CVE-2022-50924—7.9%
——2——CVE-2025-68617—7.9%
——2——CVE-2024-52557—7.9%
——2——CVE-2026-568207.4 HIG7.9%
——2Netty is a network application framework for development of protocol servers and clients. In versions 4.2.0.Final through 4.2.15.Final and prior to 4.1.135.Final, `OcspClient` does not validate that the `CertificateID` in an OCSP response matches the requested `CertificateID`, which can lead to replay attack. `OcspClient.validateResponse` accepts a legitimately signed `GOOD` status response for an unrelated certificate issued by the same CA, allowing bypass of revocation checks for another certificate. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.9dCVE-2025-36892—7.9%
——2——CVE-2023-52583—7.9%
——2——CVE-2025-0587—7.9%
——2——CVE-2025-4588—7.9%
——2——CVE-2025-7661—7.9%
——2——CVE-2025-37868—7.9%
——2——CVE-2026-40159—7.9%
——2——CVE-2024-44937—7.9%
——2——CVE-2026-35577—7.9%
——2——CVE-2024-477365.5 MED7.9%
——2In the Linux kernel, the following vulnerability has been resolved:
erofs: handle overlapped pclusters out of crafted images properly
syzbot reported a task hang issue due to a deadlock case where it is
waiting for the folio lock of a cached folio that will be used for
cache I/Os.
After looking into the crafted fuzzed image, I found it's formed with
several overlapped big pclusters as below:
Ext: logical offset | length : physical offset | length
0: 0.. 16384 | 16384 : 151552.. 167936 | 16384
1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384
2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384
...
Here, extent 0/1 are physically overlapped although it's entirely
_impossible_ for normal filesystem images generated by mkfs.
First, managed folios containing compressed data will be marked as
up-to-date and then unlocked immediately (unlike in-place folios) when
compressed I/Os are complete. If physical blocks are not submitted in
the incremental order, there should be separate BIOs to avoid dependency
issues. However, the current code mis-arranges z_erofs_fill_bio_vec()
and BIO submission which causes unexpected BIO waits.
Second, managed folios will be connected to their own pclusters for
efficient inter-queries. However, this is somewhat hard to implement
easily if overlapped big pclusters exist. Again, these only appear in
fuzzed images so let's simply fall back to temporary short-lived pages
for correctness.
Additionally, it justifies that referenced managed folios cannot be
truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy
up `struct z_erofs_bvec`") for simplicity although it shouldn't be any
difference.25dCVE-2025-50124—7.9%
——2——CVE-2026-483715.4 MED7.9%
——2Adobe Commerce is affected by a stored Cross-Site Scripting (XSS) vulnerability that could be abused by a low-privileged attacker to inject malicious scripts into vulnerable form fields. Malicious JavaScript may be executed in a victim's browser when they browse to the page containing the vulnerable field. Scope is changed.24dCVE-2023-6058—7.9%
——2——CVE-2023-49567—7.9%
——2——