Ant CVEs with no public exploit
7 CVEs, 2 protected by Waratek
Overview 7 matches · 2 protected · 0 exploited · 0 CISA KEV · 0 public PoC
Protected by Waratek
2
28.6%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
5
71.4%
blocked by ARMR today
2
28.6%
partly blocked
0
0.0%
not blocked
5
71.4%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
7
100.0%
No public exploit
0
0.0%
split by
peak 2 / quarter
Q3 201
No exploit published1
High1
not blocked1
Forecast only1
Q4 201
No exploit published1
Medium1
not blocked1
Forecast only1
Q1 211
No exploit published1
Medium1
not blocked1
Forecast only1
Q2 211
No exploit published1
High1
not blocked1
Forecast only1
Q3 211
No exploit published1
Medium1
not blocked1
Forecast only1
Q4 210
Q1 222
Protected by Waratek2
High2
blocked by ARMR today2
Forecast only2
Q3 20Q4 20Q1 21Q2 21Q3 21Q4 21Q1 22
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2022-23307 | High | 2022-01-18 | Protected by Waratek | Forecast only | CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was a component of Apache Log4j 1.2.x where the same issue exists. |
| 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-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-2021-28165 | High | 2021-04-01 | No exploit published | Forecast only | In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and 11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a large invalid TLS frame. |
| CVE-2020-27223 | Medium | 2021-02-26 | No exploit published | Forecast only | In Eclipse Jetty 9.4.6.v20170531 to 9.4.36.v20210114 (inclusive), 10.0.0, and 11.0.0 when Jetty handles a request containing multiple Accept headers with a large number of “quality” (i.e. q) parameters, the server may enter a denial of service (DoS) state due to high CPU usage processing those quality values, resulting in minutes of CPU time exhausted processing those quality values. |
| CVE-2020-13943 | Medium | 2020-10-12 | No exploit published | Forecast only | If an HTTP/2 client connecting to Apache Tomcat 10.0.0-M1 to 10.0.0-M7, 9.0.0.M1 to 9.0.37 or 8.5.0 to 8.5.57 exceeded the agreed maximum number of concurrent streams for a connection (in violation of the HTTP/2 protocol), it was possible that a subsequent request made on that connection could contain HTTP headers - including HTTP/2 pseudo headers - from a previous request rather than the intended headers. This could lead to users seeing responses for unexpected resources. |
| CVE-2020-13934 | High | 2020-07-14 | No exploit published | Forecast only | An h2c direct connection to Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M5 to 9.0.36 and 8.5.1 to 8.5.56 did not release the HTTP/1.1 processor after the upgrade to HTTP/2. If a sufficient number of such requests were made, an OutOfMemoryException could occur leading to a denial of service. |