Overview 2 matches · 1 protected · 1 exploited · 0 CISA KEV · 0 public PoC
Protected by Waratek
1
50.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
1
50.0%
blocked by ARMR today
1
50.0%
partly blocked
0
0.0%
not blocked
1
50.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
1
50.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
1
50.0%
No public exploit
0
0.0%
split by
peak 1 / month
Jul 21Aug 21Sep 21Oct 21Nov 21Dec 21
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2021-44832 | Medium | 2021-12-28 | Protected by Waratek | Exploited | Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2. |
| 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. |