integration CVEs · Protected by Waratek · Critical

Look up CVE IDs Status Exploitation Severity

Reset

Overview 11 matches · 5 exploited · 4 CISA KEV · 7 public PoC · 7 EPSS ≥ 0.5

11matches 5exploited45.5% 4CISA KEV36.4% 7public PoC63.6% 7EPSS ≥ 0.563.6%

Protected by Waratek 11 100.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 0 0.0%

Critical 11 100.0% High 0 0.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%

blocked by ARMR today 11 100.0% partly blocked 0 0.0% not blocked 0 0.0% not established 0 0.0% unrecorded 0 0.0%

Exploited 5 45.5% Working exploit published 1 9.1% Proof of concept only 1 9.1% Forecast only 0 0.0% No public exploit 4 36.4%

split by StatusSeverityProtectionExploit maturity peak 3 / year

20171 Protected by Waratek1 Critical1 blocked by ARMR today1 Working exploit published1 20182 Protected by Waratek2 Critical2 blocked by ARMR today2 Proof of concept only1 No public exploit1 20191 Protected by Waratek1 Critical1 blocked by ARMR today1 No public exploit1 20203 Protected by Waratek3 Critical3 blocked by ARMR today3 Exploited2 No public exploit1 20212 Protected by Waratek2 Critical2 blocked by ARMR today2 Exploited2 20221 Protected by Waratek1 Critical1 blocked by ARMR today1 Exploited1 20230 20240 20250 20261 Protected by Waratek1 Critical1 blocked by ARMR today1 No public exploit1

2017201820192020202120222023202420252026

11 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-47864	Critical	2026-08-27	Protected by Waratek	No public exploit	SerializingHttpMessageConverter deserializes the body of incoming HTTP requests with a raw java.io.ObjectInputStream and no class filtering. Any request with Content-Type application/x-java-serialized-object whose body resolves to a Serializable type is read directly via readObject(). If an application using this converter on an inbound HTTP endpoint has any known Java deserialization "gadget" on its classpath, a remote, unauthenticated attacker can achieve arbitrary code execution. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 Spring Integration 5.5.21 and earlier
CVE-2022-22965	Critical	2022-04-01	Protected by Waratek	Exploited	A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.
CVE-2021-45046	Critical	2021-12-14	Protected by Waratek	Exploited	It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in an information leak and remote code execution in some environments and local code execution in all environments. Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) fix this issue by removing support for message lookup patterns and disabling JNDI functionality by default.
CVE-2021-44228	Critical	2021-12-10	Protected by Waratek	Exploited	Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.
CVE-2020-17530	Critical	2020-12-11	Protected by Waratek	Exploited	Forced OGNL evaluation, when evaluated on raw user input in tag attributes, may lead to remote code execution. Affected software : Apache Struts 2.0.0 - Struts 2.5.25.
CVE-2019-0230	Critical	2020-09-14	Protected by Waratek	Exploited	Apache Struts 2.0.0 to 2.5.20 forced double OGNL evaluation, when evaluated on raw user input in tag attributes, may lead to remote code execution.
CVE-2020-10683	Critical	2020-05-01	Protected by Waratek	No public exploit	dom4j before 2.0.3 and 2.1.x before 2.1.3 allows external DTDs and External Entities by default, which might enable XXE attacks. However, there is popular external documentation from OWASP showing how to enable the safe, non-default behavior in any application that uses dom4j.
CVE-2019-3772	Critical	2019-01-18	Protected by Waratek	No public exploit	Spring Integration (spring-integration-xml and spring-integration-ws modules), versions 4.3.18, 5.0.10, 5.1.1, and older unsupported versions, were susceptible to XML External Entity Injection (XXE) when receiving XML data from untrusted sources.
CVE-2018-8013	Critical	2018-05-24	Protected by Waratek	No public exploit	In Apache Batik 1.x before 1.10, when deserializing subclass of `AbstractDocument`, the class takes a string from the inputStream as the class name which then use it to call the no-arg constructor of the class. Fix was to check the class type before calling newInstance in deserialization.
CVE-2018-1270	Critical	2018-04-06	Protected by Waratek	Proof of concept only	Spring Framework, versions 5.0 prior to 5.0.5 and versions 4.3 prior to 4.3.15 and older unsupported versions, allow applications to expose STOMP over WebSocket endpoints with a simple, in-memory STOMP broker through the spring-messaging module. A malicious user (or attacker) can craft a message to the broker that can lead to a remote code execution attack.
CVE-2017-5645	Critical	2017-04-17	Protected by Waratek	Working exploit published	In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.

CVE

Severity

Published▾

Status

Exploitation

Description

CVE-2026-47864

Critical

2026-08-27

Protected by Waratek

No public exploit

SerializingHttpMessageConverter deserializes the body of incoming HTTP requests with a raw java.io.ObjectInputStream and no class filtering. Any request with Content-Type application/x-java-serialized-object whose body resolves to a Serializable type is read directly via readObject(). If an application using this converter on an inbound HTTP endpoint has any known Java deserialization "gadget" on its classpath, a remote, unauthenticated attacker can achieve arbitrary code execution. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 Spring Integration 5.5.21 and earlier

CVE-2022-22965

Critical

2022-04-01

Protected by Waratek

Exploited

A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.

CVE-2021-45046

Critical

2021-12-14

Protected by Waratek

Exploited

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in an information leak and remote code execution in some environments and local code execution in all environments. Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) fix this issue by removing support for message lookup patterns and disabling JNDI functionality by default.

CVE-2021-44228

Critical

2021-12-10

Protected by Waratek

Exploited

Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

CVE-2020-17530

Critical

2020-12-11

Protected by Waratek

Exploited

Forced OGNL evaluation, when evaluated on raw user input in tag attributes, may lead to remote code execution. Affected software : Apache Struts 2.0.0 - Struts 2.5.25.

CVE-2019-0230

Critical

2020-09-14

Protected by Waratek

Exploited

Apache Struts 2.0.0 to 2.5.20 forced double OGNL evaluation, when evaluated on raw user input in tag attributes, may lead to remote code execution.

CVE-2020-10683

Critical

2020-05-01

Protected by Waratek

No public exploit

dom4j before 2.0.3 and 2.1.x before 2.1.3 allows external DTDs and External Entities by default, which might enable XXE attacks. However, there is popular external documentation from OWASP showing how to enable the safe, non-default behavior in any application that uses dom4j.

CVE-2019-3772

Critical

2019-01-18

Protected by Waratek

No public exploit

Spring Integration (spring-integration-xml and spring-integration-ws modules), versions 4.3.18, 5.0.10, 5.1.1, and older unsupported versions, were susceptible to XML External Entity Injection (XXE) when receiving XML data from untrusted sources.

CVE-2018-8013

Critical

2018-05-24

Protected by Waratek

No public exploit

In Apache Batik 1.x before 1.10, when deserializing subclass of `AbstractDocument`, the class takes a string from the inputStream as the class name which then use it to call the no-arg constructor of the class. Fix was to check the class type before calling newInstance in deserialization.

CVE-2018-1270

Critical

2018-04-06

Protected by Waratek

Proof of concept only

Spring Framework, versions 5.0 prior to 5.0.5 and versions 4.3 prior to 4.3.15 and older unsupported versions, allow applications to expose STOMP over WebSocket endpoints with a simple, in-memory STOMP broker through the spring-messaging module. A malicious user (or attacker) can craft a message to the broker that can lead to a remote code execution attack.

CVE-2017-5645

Critical

2017-04-17

Protected by Waratek

Working exploit published

In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.