Oracle Critical Patch Update October 2024
Released October 2024 · Oracle's advisory ↗ · ← Critical Patch Update, July 2024 · Critical Patch Update, January 2025 →
278 CVEs in this release, one square each
By status
15Protected by Waratek3Mitigation candidate88No exploit published26Outside Waratek scope144Not applicable2Withdrawn CVE
13Exploited, marked by the ring
No exploit published. For 51 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 106 matches · 15 protected · 4 exploited · 1 CISA KEV · 6 public PoC · 4 EPSS ≥ 0.5
Protected by Waratek
15
14.2%
Rule in development
0
0.0%
Mitigation candidate
3
2.8%
No exploit published
88
83.0%
blocked by ARMR today
15
14.2%
partly blocked
0
0.0%
not blocked
91
85.8%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
4
3.8%
Working exploit published
0
0.0%
Proof of concept only
7
6.6%
Forecast only
2
1.9%
No public exploit
93
87.7%
split by
peak 49 / quarter
Q4 191
Protected by Waratek1
High1
blocked by ARMR today1
No public exploit1
Q1 200
Q2 200
Q3 200
Q4 202
Protected by Waratek1
No exploit published1
Medium1
Low1
blocked by ARMR today1
not blocked1
No public exploit2
Q1 210
Q2 211
Protected by Waratek1
Critical1
blocked by ARMR today1
No public exploit1
Q3 210
Q4 211
Protected by Waratek1
High1
blocked by ARMR today1
No public exploit1
Q1 224
Protected by Waratek3
No exploit published1
Critical1
High2
Medium1
blocked by ARMR today3
not blocked1
Proof of concept only1
Forecast only2
No public exploit1
Q2 220
Q3 220
Q4 220
Q1 231
Protected by Waratek1
High1
blocked by ARMR today1
Exploited1
Q2 233
No exploit published3
High1
Medium2
not blocked3
No public exploit3
Q3 235
Protected by Waratek1
No exploit published4
High3
Medium2
blocked by ARMR today1
not blocked4
No public exploit5
Q4 236
Mitigation candidate1
No exploit published5
Critical1
High3
Medium2
not blocked6
Exploited1
No public exploit5
Q1 2414
Mitigation candidate1
No exploit published13
Critical1
High6
Medium7
not blocked14
Proof of concept only4
No public exploit10
Q2 244
Protected by Waratek1
Mitigation candidate1
No exploit published2
High4
blocked by ARMR today1
not blocked3
Exploited1
No public exploit3
Q3 2415
Protected by Waratek3
No exploit published12
Critical1
High10
Medium4
blocked by ARMR today3
not blocked12
Exploited1
Proof of concept only2
No public exploit12
Q4 2449
Protected by Waratek2
No exploit published47
Critical2
High30
Medium12
Low5
blocked by ARMR today2
not blocked47
No public exploit49
Q4 19Q2 20Q4 20Q2 21Q4 21Q2 22Q4 22Q2 23Q4 23Q2 24Q4 24
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| 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-37136 | High | 2021-10-19 | Protected by Waratek | No public exploit | The Bzip2 decompression decoder function doesn't allow setting size restrictions on the decompressed output data (which affects the allocation size used during decompression). All users of Bzip2Decoder are affected. The malicious input can trigger an OOME and so a DoS attack |
| CVE-2020-9493 | Critical | 2021-06-16 | Protected by Waratek | No public exploit | A deserialization flaw was found in Apache Chainsaw versions prior to 2.1.0 which could lead to malicious code execution. |
| CVE-2020-8908 | Low | 2020-12-10 | No exploit published | No public exploit | A temp directory creation vulnerability exists in all versions of Guava, allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava API com.google.common.io.Files.createTempDir(). By default, on unix-like systems, the created directory is world-readable (readable by an attacker with access to the system). The method in question has been marked @Deprecated in versions 30.0 and later and should not be used. For Android developers, we recommend choosing a temporary directory API provided by Android, such as context.getCacheDir(). For other Java developers, we recommend migrating to the Java 7 API java.nio.file.Files.createTempDirectory() which explicitly configures permissions of 700, or configuring the Java runtime's java.io.tmpdir system property to point to a location whose permissions are appropriately configured. |
| CVE-2020-17521 | Medium | 2020-12-07 | Protected by Waratek | No public exploit | Apache Groovy provides extension methods to aid with creating temporary directories. Prior to this fix, Groovy's implementation of those extension methods was using a now superseded Java JDK method call that is potentially not secure on some operating systems in some contexts. Users not using the extension methods mentioned in the advisory are not affected, but may wish to read the advisory for further details. Versions Affected: 2.0 to 2.4.20, 2.5.0 to 2.5.13, 3.0.0 to 3.0.6, and 4.0.0-alpha-1. Fixed in versions 2.4.21, 2.5.14, 3.0.7, 4.0.0-alpha-2. |
| CVE-2019-10172 | High | 2019-11-18 | Protected by Waratek | No public exploit | A flaw was found in org.codehaus.jackson:jackson-mapper-asl:1.9.x libraries. XML external entity vulnerabilities similar CVE-2016-3720 also affects codehaus jackson-mapper-asl libraries but in different classes. |