WaratekVRT Sign in
Reset
More filters (2)
Columns
Protection: Full✕Vendor broadcom✕
Overview 9 matches · 1 exploited · 1 CISA KEV · 2 public PoC · 3 EPSS ≥ 0.5
9matches 1exploited11.1% 1CISA KEV11.1% 2public PoC22.2% 3EPSS ≥ 0.533.3%
Protected by Waratek 9 100.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 0 0.0%
Critical 5 55.6% High 3 33.3% Medium 1 11.1% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 9 100.0% partly blocked 0 0.0% not blocked 0 0.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 1 11.1% Working exploit published 0 0.0% Proof of concept only 1 11.1% Forecast only 1 11.1% No public exploit 6 66.7%
split by peak 3 / year
Protected by Waratek: 9 Medium: 1High: 3Critical: 5 blocked by ARMR today: 9 No public exploit: 6Forecast only: 1Proof of concept only: 1Exploited: 1
20182 Protected by Waratek2 Critical1 High1 blocked by ARMR today2 Exploited1 No public exploit1 20192 Protected by Waratek2 Critical2 blocked by ARMR today2 No public exploit2 20200 20210 20222 Protected by Waratek2 Critical1 High1 blocked by ARMR today2 Proof of concept only1 Forecast only1 20230 20240 20250 20263 Protected by Waratek3 Critical1 High1 Medium1 blocked by ARMR today3 No public exploit3
201820192020202120222023202420252026
9 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2026-47875 Critical 2026-08-27 Protected by Waratek No public exploit Applications that deserialize execution contexts with Jackson2ExecutionContextStringSerializer are vulnerable to a deserialization attack if they use an untrusted data source for the job repository. The JobParameterDeserializer does not properly enforce the trusted-types allowlist, allowing an attacker to craft malicious input that can lead to arbitrary code execution, including known Jackson RCE gadgets. Spring Batch 6.0.0 - 6.0.4 Spring Batch 5.2.0 - 5.2.6
CVE-2026-40998 High 2026-06-11 Protected by Waratek No public exploit Jaxp13XPathTemplate evaluated XPath expressions for StreamSource and SAXSource inputs using a code path that parsed attacker-controlled XML with the JDK's default DocumentBuilderFactory behavior instead of Spring's hardened parser configuration. Applications that evaluate XPath against untrusted XML payloads could therefore be exposed to XML External Entity (XXE) style attacks. Affected versions: Spring Web Services 5.0.0 through 5.0.1; 4.1.0 through 4.1.3; 4.0.0 through 4.0.18; 3.1.0 through 3.1.8.
CVE-2026-40991 Medium 2026-06-10 Protected by Waratek No public exploit When using spring-restdocs-webtestclient or spring-restdocs-restassured to document a remote API accessed over HTTP, an attacker who compromises the API or tricks the user into documenting a malicious API can perform an XXE injection attack when the documentation-generating tests are next executed. Affected versions: Spring REST Docs 4.0.0; 3.0.0 through 3.0.5; 2.0.0.RELEASE through 2.0.8.RELEASE.
CVE-2022-23305 Critical 2022-01-18 Protected by Waratek Proof of concept only By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.
CVE-2022-23302 High 2022-01-18 Protected by Waratek Forecast only JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104. Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.
CVE-2019-3774 Critical 2019-01-18 Protected by Waratek No public exploit Spring Batch versions 3.0.9, 4.0.1, 4.1.0, and older unsupported versions, were susceptible to XML External Entity Injection (XXE) when receiving XML data from untrusted sources.
CVE-2019-3773 Critical 2019-01-18 Protected by Waratek No public exploit Spring Web Services, versions 2.4.3, 3.0.4, and older unsupported versions of all three projects, were susceptible to XML External Entity Injection (XXE) when receiving XML data from untrusted sources.
CVE-2018-1259 High 2018-05-11 Protected by Waratek No public exploit Spring Data Commons, versions 1.13 prior to 1.13.12 and 2.0 prior to 2.0.7, used in combination with XMLBeam 1.4.14 or earlier versions, contains a property binder vulnerability caused by improper restriction of XML external entity references as underlying library XMLBeam does not restrict external reference expansion. An unauthenticated remote malicious user can supply specially crafted request parameters against Spring Data's projection-based request payload binding to access arbitrary files on the system.
CVE-2018-1273 Critical 2018-04-11 Protected by Waratek Exploited Spring Data Commons, versions prior to 1.13 to 1.13.10, 2.0 to 2.0.5, and older unsupported versions, contain a property binder vulnerability caused by improper neutralization of special elements. An unauthenticated remote malicious user (or attacker) can supply specially crafted request parameters against Spring Data REST backed HTTP resources or using Spring Data's projection-based request payload binding hat can lead to a remote code execution attack.