Overview 5 matches · 2 protected · 2 exploited · 2 CISA KEV · 4 public PoC
Protected by Waratek
2
40.0%
Rule in development
0
0.0%
Mitigation candidate
2
40.0%
No exploit published
1
20.0%
blocked by ARMR today
2
40.0%
partly blocked
0
0.0%
not blocked
3
60.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
2
40.0%
Working exploit published
2
40.0%
Proof of concept only
0
0.0%
Forecast only
1
20.0%
No public exploit
0
0.0%
split by
peak 1 / quarter
Q2 201
Protected by Waratek1
High1
blocked by ARMR today1
Working exploit published1
Q3 201
Mitigation candidate1
High1
not blocked1
Working exploit published1
Q4 200
Q1 210
Q2 210
Q3 211
No exploit published1
Medium1
not blocked1
Forecast only1
Q4 211
Protected by Waratek1
Critical1
blocked by ARMR today1
Exploited1
Q1 220
Q2 220
Q3 220
Q4 220
Q1 230
Q2 230
Q3 230
Q4 231
Mitigation candidate1
High1
not blocked1
Exploited1
Q2 20Q4 20Q2 21Q4 21Q2 22Q4 22Q2 23Q4 23
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2023-44487 | High | 2023-10-10 | Mitigation candidate | Exploited | The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. |
| 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-2021-33037 | Medium | 2021-07-12 | No exploit published | Forecast only | Apache Tomcat 10.0.0-M1 to 10.0.6, 9.0.0.M1 to 9.0.46 and 8.5.0 to 8.5.66 did not correctly parse the HTTP transfer-encoding request header in some circumstances leading to the possibility to request smuggling when used with a reverse proxy. Specifically: - Tomcat incorrectly ignored the transfer encoding header if the client declared it would only accept an HTTP/1.0 response; - Tomcat honoured the identify encoding; and - Tomcat did not ensure that, if present, the chunked encoding was the final encoding. |
| CVE-2020-13935 | High | 2020-07-14 | Mitigation candidate | Working exploit published | The payload length in a WebSocket frame was not correctly validated in Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M1 to 9.0.36, 8.5.0 to 8.5.56 and 7.0.27 to 7.0.104. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service. |
| CVE-2020-9484 | High | 2020-05-20 | Protected by Waratek | Working exploit published | When using Apache Tomcat versions 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54 and 7.0.0 to 7.0.103 if a) an attacker is able to control the contents and name of a file on the server; and b) the server is configured to use the PersistenceManager with a FileStore; and c) the PersistenceManager is configured with sessionAttributeValueClassNameFilter="null" (the default unless a SecurityManager is used) or a sufficiently lax filter to allow the attacker provided object to be deserialized; and d) the attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over; then, using a specifically crafted request, the attacker will be able to trigger remote code execution via deserialization of the file under their control. Note that all of conditions a) to d) must be true for the attack to succeed. |