Oracle Critical Patch Update July 2022
Released July 2022 · Oracle's advisory ↗ · ← Critical Patch Update, April 2022 · Critical Patch Update, October 2022 →
188 CVEs in this release, one square each
By status
27Protected by Waratek6Mitigation candidate72No exploit published49Outside Waratek scope34Not applicable
12Exploited, marked by the ring
No exploit published. For 47 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 7 matches · 3 protected · 0 exploited · 0 CISA KEV · 4 public PoC · 2 EPSS ≥ 0.5
Protected by Waratek
3
42.9%
Rule in development
0
0.0%
Mitigation candidate
2
28.6%
No exploit published
2
28.6%
blocked by ARMR today
3
42.9%
partly blocked
0
0.0%
not blocked
4
57.1%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
7
100.0%
Forecast only
0
0.0%
No public exploit
0
0.0%
split by
peak 2 / month
Jan 221
Protected by Waratek1
Critical1
blocked by ARMR today1
Proof of concept only1
Feb 221
No exploit published1
High1
not blocked1
Proof of concept only1
Mar 220
Apr 221
Protected by Waratek1
Critical1
blocked by ARMR today1
Proof of concept only1
May 222
Mitigation candidate1
No exploit published1
Critical1
Medium1
not blocked2
Proof of concept only2
Jun 221
Mitigation candidate1
Critical1
not blocked1
Proof of concept only1
Jul 221
Protected by Waratek1
High1
blocked by ARMR today1
Proof of concept only1
Jan 22Feb 22Mar 22Apr 22May 22Jun 22Jul 22
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2022-34169 | High | 2022-07-19 | Protected by Waratek | Proof of concept only | The Apache Xalan Java XSLT library is vulnerable to an integer truncation issue when processing malicious XSLT stylesheets. This can be used to corrupt Java class files generated by the internal XSLTC compiler and execute arbitrary Java bytecode. Users are recommended to update to version 2.7.3 or later. Note: Java runtimes (such as OpenJDK) include repackaged copies of Xalan. |
| CVE-2022-25845 | Critical | 2022-06-10 | Mitigation candidate | Proof of concept only | The package com.alibaba:fastjson before 1.2.83 are vulnerable to Deserialization of Untrusted Data by bypassing the default autoType shutdown restrictions, which is possible under certain conditions. Exploiting this vulnerability allows attacking remote servers. Workaround: If upgrading is not possible, you can enable [safeMode](https://github.com/alibaba/fastjson/wiki/fastjson_safemode). |
| CVE-2022-22978 | Critical | 2022-05-19 | Mitigation candidate | Proof of concept only | In spring security versions prior to 5.4.11+, 5.5.7+ , 5.6.4+ and older unsupported versions, RegexRequestMatcher can easily be misconfigured to be bypassed on some servlet containers. Applications using RegexRequestMatcher with `.` in the regular expression are possibly vulnerable to an authorization bypass. |
| CVE-2022-24823 | Medium | 2022-05-06 | No exploit published | Proof of concept only | Netty is an open-source, asynchronous event-driven network application framework. The package `io.netty:netty-codec-http` prior to version 4.1.77.Final contains an insufficient fix for CVE-2021-21290. When Netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. This only impacts applications running on Java version 6 and lower. Additionally, this vulnerability impacts code running on Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users. Version 4.1.77.Final contains a patch for this vulnerability. As a workaround, specify one's own `java.io.tmpdir` when starting the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user. |
| CVE-2022-23457 | Critical | 2022-04-25 | Protected by Waratek | Proof of concept only | ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library. Prior to version 2.3.0.0, the default implementation of `Validator.getValidDirectoryPath(String, String, File, boolean)` may incorrectly treat the tested input string as a child of the specified parent directory. This potentially could allow control-flow bypass checks to be defeated if an attack can specify the entire string representing the 'input' path. This vulnerability is patched in release 2.3.0.0 of ESAPI. As a workaround, it is possible to write one's own implementation of the Validator interface. However, maintainers do not recommend this. |
| CVE-2021-43859 | High | 2022-02-01 | No exploit published | Proof of concept only | XStream is an open source java library to serialize objects to XML and back again. Versions prior to 1.4.19 may allow a remote attacker to allocate 100% CPU time on the target system depending on CPU type or parallel execution of such a payload resulting in a denial of service only by manipulating the processed input stream. XStream 1.4.19 monitors and accumulates the time it takes to add elements to collections and throws an exception if a set threshold is exceeded. Users are advised to upgrade as soon as possible. Users unable to upgrade may set the NO_REFERENCE mode to prevent recursion. See GHSA-rmr5-cpv2-vgjf for further details on a workaround if an upgrade is not possible. |
| CVE-2022-23305 | Critical | 2022-01-18 | Protected by Waratek | Proof of concept only | By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. 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. |