Oracle Critical Patch Update October 2022
Released October 2022 · Oracle's advisory ↗ · ← Critical Patch Update, July 2022 · Critical Patch Update, January 2023 →
179 CVEs in this release, one square each
By status
25Protected by Waratek4Mitigation candidate55No exploit published48Outside Waratek scope47Not applicable
10Exploited, marked by the ring
No exploit published. For 33 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 16 matches · 8 in Waratek scope · 6 protected · 7 exploited · 2 CISA KEV · 10 public PoC
Protected by Waratek
6
37.5%
Rule in development
0
0.0%
Mitigation candidate
1
6.2%
No exploit published
1
6.2%
Outside Waratek scope
5
31.2%
Not applicable
3
18.8%
Withdrawn CVE
0
0.0%
blocked by ARMR today
6
37.5%
partly blocked
0
0.0%
not blocked
10
62.5%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
7
43.8%
Working exploit published
2
12.5%
Proof of concept only
4
25.0%
Forecast only
3
18.8%
No public exploit
0
0.0%
split by
peak 4 / quarter
Q2 201
Outside Waratek scope1
Medium1
not blocked1
Exploited1
Q3 200
Q4 200
Q1 210
Q2 211
No exploit published1
High1
not blocked1
Forecast only1
Q3 211
Protected by Waratek1
Medium1
blocked by ARMR today1
Exploited1
Q4 213
Protected by Waratek2
Outside Waratek scope1
Critical1
High1
Medium1
blocked by ARMR today2
not blocked1
Exploited2
Working exploit published1
Q1 224
Protected by Waratek1
Outside Waratek scope1
Not applicable2
Critical2
High2
blocked by ARMR today1
not blocked3
Exploited1
Proof of concept only2
Forecast only1
Q2 224
Protected by Waratek1
Mitigation candidate1
Outside Waratek scope2
Critical3
High1
blocked by ARMR today1
not blocked3
Exploited1
Working exploit published1
Proof of concept only2
Q3 221
Not applicable1
Medium1
not blocked1
Forecast only1
Q4 221
Protected by Waratek1
Critical1
blocked by ARMR today1
Exploited1
Q2 20Q3 20Q4 20Q1 21Q2 21Q3 21Q4 21Q1 22Q2 22Q3 22Q4 22
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2022-21587 | Critical | 2022-10-18 | Protected by Waratek | Exploited | Vulnerability in the Oracle Web Applications Desktop Integrator product of Oracle E-Business Suite (component: Upload). Supported versions that are affected are 12.2.3-12.2.11. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Web Applications Desktop Integrator. Successful attacks of this vulnerability can result in takeover of Oracle Web Applications Desktop Integrator. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). |
| CVE-2022-32215 | Medium | 2022-07-14 | Not applicable | Forecast only | The llhttp parser <v14.20.1, <v16.17.1 and <v18.9.1 in the http module in Node.js does not correctly handle multi-line Transfer-Encoding headers. This can lead to HTTP Request Smuggling (HRS). |
| CVE-2022-2068 | Critical | 2022-06-21 | Outside Waratek scope | Proof of concept only | In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances where the c_rehash script does not properly sanitise shell metacharacters to prevent command injection were found by code review. When the CVE-2022-1292 was fixed it was not discovered that there are other places in the script where the file names of certificates being hashed were possibly passed to a command executed through the shell. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.4 (Affected 3.0.0,3.0.1,3.0.2,3.0.3). Fixed in OpenSSL 1.1.1p (Affected 1.1.1-1.1.1o). Fixed in OpenSSL 1.0.2zf (Affected 1.0.2-1.0.2ze). |
| CVE-2022-29885 | High | 2022-05-12 | Mitigation candidate | Working exploit published | The documentation of Apache Tomcat 10.1.0-M1 to 10.1.0-M14, 10.0.0-M1 to 10.0.20, 9.0.13 to 9.0.62 and 8.5.38 to 8.5.78 for the EncryptInterceptor incorrectly stated it enabled Tomcat clustering to run over an untrusted network. This was not correct. While the EncryptInterceptor does provide confidentiality and integrity protection, it does not protect against all risks associated with running over any untrusted network, particularly DoS risks. |
| CVE-2022-1292 | Critical | 2022-05-03 | Outside Waratek scope | Proof of concept only | The c_rehash script does not properly sanitise shell metacharacters to prevent command injection. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). Fixed in OpenSSL 1.1.1o (Affected 1.1.1-1.1.1n). Fixed in OpenSSL 1.0.2ze (Affected 1.0.2-1.0.2zd). |
| CVE-2021-31805 | Critical | 2022-04-12 | Protected by Waratek | Exploited | The fix issued for CVE-2020-17530 was incomplete. So from Apache Struts 2.0.0 to 2.5.29, still some of the tag’s attributes could perform a double evaluation if a developer applied forced OGNL evaluation by using the %{...} syntax. Using forced OGNL evaluation on untrusted user input can lead to a Remote Code Execution and security degradation. |
| CVE-2018-25032 | High | 2022-03-25 | Outside Waratek scope | Proof of concept only | zlib before 1.2.12 allows memory corruption when deflating (i.e., when compressing) if the input has many distant matches. |
| CVE-2022-23943 | Critical | 2022-03-14 | Not applicable | Forecast only | Out-of-bounds Write vulnerability in mod_sed of Apache HTTP Server allows an attacker to overwrite heap memory with possibly attacker provided data. This issue affects Apache HTTP Server 2.4 version 2.4.52 and prior versions. |
| CVE-2021-4034 | High | 2022-01-28 | Not applicable | Exploited | A local privilege escalation vulnerability was found on polkit's pkexec utility. The pkexec application is a setuid tool designed to allow unprivileged users to run commands as privileged users according predefined policies. The current version of pkexec doesn't handle the calling parameters count correctly and ends trying to execute environment variables as commands. An attacker can leverage this by crafting environment variables in such a way it'll induce pkexec to execute arbitrary code. When successfully executed the attack can cause a local privilege escalation given unprivileged users administrative rights on the target machine. |
| 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. |
| 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-44790 | Critical | 2021-12-20 | Outside Waratek scope | Working exploit published | A carefully crafted request body can cause a buffer overflow in the mod_lua multipart parser (r:parsebody() called from Lua scripts). The Apache httpd team is not aware of an exploit for the vulnerabilty though it might be possible to craft one. This issue affects Apache HTTP Server 2.4.51 and earlier. |
| CVE-2021-4104 | High | 2021-12-14 | Protected by Waratek | Exploited | JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, 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-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-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-11022 | Medium | 2020-04-29 | Outside Waratek scope | Exploited | In jQuery starting with 1.12.0 and before 3.5.0, passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0. |