Oracle Critical Patch Update January 2022
Released January 2022 · Oracle's advisory ↗ · ← Critical Patch Update, October 2021 · Critical Patch Update, April 2022 →
266 CVEs in this release, one square each
By status
34Protected by Waratek3Mitigation candidate100No exploit published57Outside Waratek scope72Not applicable
13Exploited, marked by the ring
No exploit published. For 71 of them, Oracle's security advisory is the source of public detail.
Protected by Waratek. Waratek RASP can block exploitation of these on systems that have not applied the patch yet.
Overview 5 matches · 4 protected · 3 exploited · 0 CISA KEV · 3 public PoC
Protected by Waratek
4
80.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
1
20.0%
blocked by ARMR today
4
80.0%
partly blocked
0
0.0%
not blocked
1
20.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
3
60.0%
Working exploit published
1
20.0%
Proof of concept only
0
0.0%
Forecast only
1
20.0%
No public exploit
0
0.0%
split by
peak 2 / month
Apr 211
Protected by Waratek1
Medium1
blocked by ARMR today1
Working exploit published1
May 210
Jun 210
Jul 212
Protected by Waratek1
No exploit published1
Medium2
blocked by ARMR today1
not blocked1
Exploited1
Forecast only1
Aug 210
Sep 210
Oct 210
Nov 210
Dec 212
Protected by Waratek2
Medium2
blocked by ARMR today2
Exploited2
Apr 21May 21Jun 21Jul 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-45105 | Medium | 2021-12-18 | Protected by Waratek | Exploited | Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0, 2.12.3, and 2.3.1. |
| CVE-2021-34429 | Medium | 2021-07-15 | Protected by Waratek | Exploited | For Eclipse Jetty versions 9.4.37-9.4.42, 10.0.1-10.0.5 & 11.0.1-11.0.5, URIs can be crafted using some encoded characters to access the content of the WEB-INF directory and/or bypass some security constraints. This is a variation of the vulnerability reported in CVE-2021-28164/GHSA-v7ff-8wcx-gmc5. |
| 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-28164 | Medium | 2021-04-01 | Protected by Waratek | Working exploit published | In Eclipse Jetty 9.4.37.v20210219 to 9.4.38.v20210224, the default compliance mode allows requests with URIs that contain %2e or %2e%2e segments to access protected resources within the WEB-INF directory. For example a request to /context/%2e/WEB-INF/web.xml can retrieve the web.xml file. This can reveal sensitive information regarding the implementation of a web application. |