Vulnerabilities exploitable today
405,327in 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,762
New KEV · 24H0
Exploit Today ≥ 701,694
Distribution · last window
- Critical5,616
- High21,702
- Medium20,076
- Low2,086
Filters
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2017-13713—95.3%
——29——CVE-2022-37987—95.3%
——29——CVE-2003-0254—95.3%
——29——CVE-2022-0827—95.3%
——29——CVE-2011-2194—95.3%
——29——CVE-2025-49198.8 HIG95.3%
——29An attacker was able to perform an out-of-bounds read or write on a JavaScript object by confusing array index sizes. This vulnerability was fixed in Firefox 138.0.4, Firefox ESR 128.10.1, Firefox ESR 115.23.1, Thunderbird 128.10.2, and Thunderbird 138.0.2.29dCVE-2004-0782—95.3%
——29——CVE-2025-599349.4 CRI95.3%
——29Formbricks is an open source qualtrics alternative. Prior to version 4.0.1, Formbricks is missing JWT signature verification. This vulnerability stems from a token validation routine that only decodes JWTs (jwt.decode) without verifying their signatures. Both the email verification token login path and the password reset server action use the same validator, which does not check the token’s signature, expiration, issuer, or audience. If an attacker learns the victim’s actual user.id, they can craft an arbitrary JWT with an alg: "none" header and use it to authenticate and reset the victim’s password. This issue has been patched in version 4.0.1.10dCVE-2005-2390—95.3%
——29——CVE-2024-34921—95.3%
——29——CVE-2026-2530—95.3%
——29——CVE-2011-5219—95.3%
——29——CVE-2018-5043—95.3%
——29——CVE-2023-47681—95.3%
——29——CVE-2003-0044—95.3%
——29——CVE-2020-11800—95.3%
——29——CVE-2023-4430—95.3%
——29——CVE-2017-15662—95.3%
——29——CVE-2004-0432—95.3%
——29——CVE-2008-0623—95.3%
——29——CVE-2007-6276—95.3%
——29——CVE-2021-46360—95.3%
——29——CVE-2025-29774—95.3%
——29——CVE-2004-0769—95.3%
——29——CVE-2026-3345310.0 CRI95.3%
——29Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in Apache Camel Camel-Coap component.
Apache Camel's camel-coap component is vulnerable to Camel message header injection, leading to remote code execution when routes forward CoAP requests to header-sensitive producers (e.g. camel-exec)
The camel-coap component maps incoming CoAP request URI query parameters directly into Camel Exchange In message headers without applying any HeaderFilterStrategy.
Specifically, CamelCoapResource.handleRequest() iterates over OptionSet.getUriQuery() and calls camelExchange.getIn().setHeader(...) for every query parameter. CoAPEndpoint extends DefaultEndpoint rather than DefaultHeaderFilterStrategyEndpoint, and CoAPComponent does not implement HeaderFilterStrategyComponent; the component contains no references to HeaderFilterStrategy at all.
As a result, an unauthenticated attacker who can send a single CoAP UDP packet to a Camel route consuming from coap:// can inject arbitrary Camel internal headers (those prefixed with Camel*) into the Exchange. When the route delivers the message to a header-sensitive producer such as camel-exec, camel-sql, camel-bean, camel-file, or template components (camel-freemarker, camel-velocity), the injected headers can alter the producer's behavior. In the case of camel-exec, the CamelExecCommandExecutable and CamelExecCommandArgs headers override the executable and arguments configured on the endpoint, resulting in arbitrary OS command execution under the privileges of the Camel process.
The producer's output is written back to the Exchange body and returned in the CoAP response payload by CamelCoapResource, giving the attacker an interactive RCE channel without any need for out-of-band exfiltration.
Exploitation prerequisites are minimal: a single unauthenticated UDP datagram to the CoAP port (default 5683). CoAP (RFC 7252) has no built-in authentication, and DTLS is optional and disabled by default. Because the protocol is UDP-based, HTTP-layer WAF/IDS controls do not apply.
This issue affects Apache Camel: from 4.14.0 through 4.14.5, from 4.18.0 before 4.18.1, 4.19.0.
Users are recommended to upgrade to version 4.18.1 or 4.19.0, fixing the issue.3dCVE-2004-1300—95.3%
——29——CVE-2022-45672—95.3%
——29——CVE-2020-11897—95.3%
——29——CVE-2014-3848—95.3%
——29——CVE-2012-0991—95.3%
——29——CVE-2022-26982—95.3%
——29——CVE-2005-3670—95.3%
——29——CVE-2005-4211—95.3%
——29——CVE-2014-3577—95.3%
——29——CVE-2014-8997—95.3%
——29——CVE-2023-317427.2 HIG95.3%
——29There is a command injection vulnerability in the Linksys WRT54GL router with firmware version 4.30.18.006. If an attacker gains web management privileges, they can inject commands into the post request parameters wl_ant, wl_rate, WL_atten_ctl, ttcp_num, ttcp_size in the httpd s Start_EPI() function, thereby gaining shell privileges.113dCVE-2021-43495—95.3%
——29——CVE-2026-93128.2 HIG95.3%
——29A server-side request forgery (SSRF) vulnerability was identified in GitHub Enterprise Server that allowed an unauthenticated attacker to send crafted requests to internal services by exploiting insufficient input validation in an upload endpoint. By injecting path traversal content into request parameters, an attacker could bypass the intended request flow and redirect internal API calls, potentially accessing internal services and exposing sensitive credentials. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.22 and was fixed in versions 3.17.17, 3.18.11, 3.19.8, 3.20.4, and 3.21.2. This vulnerability was reported via the GitHub Bug Bounty program.98dCVE-2012-44314.3 NO 95.3%
——29org/apache/catalina/filters/CsrfPreventionFilter.java in Apache Tomcat 6.x before 6.0.36 and 7.x before 7.0.32 allows remote attackers to bypass the cross-site request forgery (CSRF) protection mechanism via a request that lacks a session identifier.20dCVE-2023-43662—95.3%
——29——