Vulnerabilities exploitable today
360,723in 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,665
New KEV · 24H0
Exploit Today ≥ 701,608
Distribution · last window
- Critical2,508
- High11,064
- Medium7,110
- Low642
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2021-29577—11.6%
——3——CVE-2021-29578—11.6%
——3——CVE-2025-231427.8 HIG11.6%
——3In the Linux kernel, the following vulnerability has been resolved:
sctp: detect and prevent references to a freed transport in sendmsg
sctp_sendmsg() re-uses associations and transports when possible by
doing a lookup based on the socket endpoint and the message destination
address, and then sctp_sendmsg_to_asoc() sets the selected transport in
all the message chunks to be sent.
There's a possible race condition if another thread triggers the removal
of that selected transport, for instance, by explicitly unbinding an
address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have
been set up and before the message is sent. This can happen if the send
buffer is full, during the period when the sender thread temporarily
releases the socket lock in sctp_wait_for_sndbuf().
This causes the access to the transport data in
sctp_outq_select_transport(), when the association outqueue is flushed,
to result in a use-after-free read.
This change avoids this scenario by having sctp_transport_free() signal
the freeing of the transport, tagging it as "dead". In order to do this,
the patch restores the "dead" bit in struct sctp_transport, which was
removed in
commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").
Then, in the scenario where the sender thread has released the socket
lock in sctp_wait_for_sndbuf(), the bit is checked again after
re-acquiring the socket lock to detect the deletion. This is done while
holding a reference to the transport to prevent it from being freed in
the process.
If the transport was deleted while the socket lock was relinquished,
sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the
send.
The bug was found by a private syzbot instance (see the error report [1]
and the C reproducer that triggers it [2]).17dCVE-2025-41404—11.6%
——3——CVE-2025-30235—11.6%
——3——CVE-2025-6643—11.6%
——3——CVE-2026-24564—11.6%
——3——CVE-2021-25749—11.6%
——3——CVE-2021-47608—11.6%
——3——CVE-2025-6656—11.6%
——3——CVE-2026-0505—11.6%
——3——CVE-2021-31406—11.6%
——3——CVE-2025-6657—11.6%
——3——CVE-2018-15773—11.6%
——3——CVE-2019-4220—11.6%
——3——CVE-2025-6648—11.6%
——3——CVE-2023-50228—11.6%
——3——CVE-2024-23440—11.6%
——3——CVE-2022-32231—11.6%
——3——CVE-2025-5143—11.6%
——3——CVE-2023-43800—11.6%
——3——CVE-2020-25168—11.6%
——3——CVE-2024-50025—11.6%
——3——CVE-2026-33223—11.6%
——3——CVE-2025-4367—11.6%
——3——CVE-2026-417066.1 MED11.6%
——3Spring Security's CookieRequestCache and CookieServerRequestCache store the pre-authentication request URL in a browser cookie so that users can be redirected back to their intended destination after a successful login. In affected versions, the full absolute URL is stored in the cookie and is used without validation as the post-login redirect target.
Affected versions:
Spring Security 5.7.0 through 5.7.23; 5.8.0 through 5.8.25; 6.3.0 through 6.3.16; 6.4.0 through 6.4.16; 6.5.0 through 6.5.10; 7.0.0 through 7.0.5.24dCVE-2025-66099—11.6%
——3——CVE-2022-49853—11.6%
——3——CVE-2022-35292—11.6%
——3——CVE-2024-49972—11.6%
——3——CVE-2024-49921—11.6%
——3——CVE-2026-637424.3 MED11.6%
——3SurrealDB versions before 3.1.0 contain a field-level SELECT permission bypass vulnerability in indexed COUNT fast paths. Attackers can execute COUNT queries on indexed fields with field-level SELECT restrictions to confirm or recover restricted field values through repeated guesses.25dCVE-2026-393546.5 MED11.6%
——3Scoold is a Q&A and a knowledge sharing platform for teams. Prior to 1.66.2, an authenticated authorization flaw in Scoold allows any logged-in, low-privilege user to overwrite another user's existing question by supplying that question's public ID as the postId parameter to POST /questions/ask. Because question IDs are exposed in normal question URLs, a low-privilege attacker can take a victim question ID from a public page and cause attacker-controlled content to be stored under that existing question object. This causes direct integrity loss of user-generated content and corrupts the integrity of the existing discussion thread. This vulnerability is fixed in 1.66.2.23dCVE-2026-60758.1 HIG11.6%
——3The Media Library Assistant plugin for WordPress is vulnerable to Cross-Site Request Forgery in versions up to, and including, 3.35 This is due to missing nonce verification on the bulk action handlers in the settings tab handlers. This makes it possible for unauthenticated attackers to trick an administrator into performing bulk delete, edit, or purge operations on plugin settings and attachment metadata via a forged request.26dCVE-2025-21905—11.6%
——3——CVE-2025-66107—11.6%
——3——CVE-2026-622165.0 MED11.6%
——3OpenClaw 2026.4.20 before 2026.5.28 contain a policy bypass in the QQBot media upload feature. A lower-trust caller or configured input path could cause the media upload to reach network destinations that should have been blocked by OpenClaw policy (server-side request forgery). The practical impact depends on the operator's configuration and whether lower-trust input can reach that path.24dCVE-2021-29536—11.6%
——3——CVE-2024-11916—11.6%
——3——CVE-2021-476047.1 HIG11.6%
——3In the Linux kernel, the following vulnerability has been resolved:
vduse: check that offset is within bounds in get_config()
This condition checks "len" but it does not check "offset" and that
could result in an out of bounds read if "offset > dev->config_size".
The problem is that since both variables are unsigned the
"dev->config_size - offset" subtraction would result in a very high
unsigned value.
I think these checks might not be necessary because "len" and "offset"
are supposed to already have been validated using the
vhost_vdpa_config_validate() function. But I do not know the code
perfectly, and I like to be safe.12d