Oracle Critical Patch Update January 2025
Released January 2025 · Oracle's advisory ↗ · ← Critical Patch Update, October 2024 · Critical Patch Update, April 2025 →
253 CVEs in this release, one square each
By status
13Protected by Waratek4Mitigation candidate86No exploit published17Outside Waratek scope133Not applicable
11Exploited, marked by the ring
No exploit published. For 48 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 215 matches · 89 in Waratek scope · 6 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
215matches
89in Waratek scope41.4%
6protected2.8%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
6
2.8%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
83
38.6%
Outside Waratek scope
9
4.2%
Not applicable
117
54.4%
Withdrawn CVE
0
0.0%
blocked by ARMR today
6
2.8%
partly blocked
0
0.0%
not blocked
209
97.2%
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
0
0.0%
No public exploit
215
100.0%
split by
peak 84 / quarter
Q2 191
Not applicable1
Medium1
not blocked1
No public exploit1
Q3 192
No exploit published1
Not applicable1
Critical1
Medium1
not blocked2
No public exploit2
Q4 191
Protected by Waratek1
Medium1
blocked by ARMR today1
No public exploit1
Q1 200
Q2 201
No exploit published1
High1
not blocked1
No public exploit1
Q3 200
Q4 203
No exploit published2
Outside Waratek scope1
High2
Medium1
not blocked3
No public exploit3
Q1 211
Protected by Waratek1
Critical1
blocked by ARMR today1
No public exploit1
Q2 213
Protected by Waratek1
No exploit published2
High2
Medium1
blocked by ARMR today1
not blocked2
No public exploit3
Q3 211
Not applicable1
High1
not blocked1
No public exploit1
Q4 210
Q1 220
Q2 220
Q3 221
No exploit published1
High1
not blocked1
No public exploit1
Q4 220
Q1 233
No exploit published1
Not applicable2
High2
Medium1
not blocked3
No public exploit3
Q2 234
No exploit published1
Not applicable3
High2
Medium2
not blocked4
No public exploit4
Q3 2311
Protected by Waratek1
No exploit published1
Not applicable9
Critical1
High6
Medium4
blocked by ARMR today1
not blocked10
No public exploit11
Q4 2316
No exploit published3
Not applicable13
Critical1
High5
Medium10
not blocked16
No public exploit16
Q1 2421
No exploit published7
Not applicable14
Critical1
High9
Medium11
not blocked21
No public exploit21
Q2 2426
No exploit published7
Outside Waratek scope4
Not applicable15
Critical3
High15
Medium8
not blocked26
No public exploit26
Q3 2422
Protected by Waratek1
No exploit published4
Not applicable17
Critical4
High9
Medium7
Low2
blocked by ARMR today1
not blocked21
No public exploit22
Q4 2414
Protected by Waratek1
No exploit published8
Outside Waratek scope2
Not applicable3
Critical2
High3
Medium8
Low1
blocked by ARMR today1
not blocked13
No public exploit14
Q1 2584
No exploit published44
Outside Waratek scope2
Not applicable38
Critical3
High13
Medium65
Low3
not blocked84
No public exploit84
Q3 19Q1 20Q3 20Q1 21Q3 21Q1 22Q3 22Q1 23Q3 23Q1 24Q3 24Q1 25
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2022-26345 | High | 2023-02-16 | Not applicable | No public exploit | Uncontrolled search path element in the Intel(R) oneAPI Toolkit OpenMP before version 2022.1 may allow an authenticated user to potentially enable escalation of privilege via local access. |
| CVE-2022-40150 | High | 2022-09-16 | No exploit published | No public exploit | Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. |
| CVE-2021-32751 | High | 2021-07-20 | Not applicable | No public exploit | Gradle is a build tool with a focus on build automation. In versions prior to 7.2, start scripts generated by the `application` plugin and the `gradlew` script are both vulnerable to arbitrary code execution when an attacker is able to change environment variables for the user running the script. This may impact those who use `gradlew` on Unix-like systems or use the scripts generated by Gradle in thieir application on Unix-like systems. For this vulnerability to be exploitable, an attacker needs to be able to set the value of particular environment variables and have those environment variables be seen by the vulnerable scripts. This issue has been patched in Gradle 7.2 by removing the use of `eval` and requiring the use of the `bash` shell. There are a few workarounds available. For CI/CD systems using the Gradle build tool, one may ensure that untrusted users are unable to change environment variables for the user that executes `gradlew`. If one is unable to upgrade to Gradle 7.2, one may generate a new `gradlew` script with Gradle 7.2 and use it for older versions of Gradle. Fpplications using start scripts generated by Gradle, one may ensure that untrusted users are unable to change environment variables for the user that executes the start script. A vulnerable start script could be manually patched to remove the use of `eval` or the use of environment variables that affect the application's command-line. If the application is simple enough, one may be able to avoid the use of the start scripts by running the application directly with Java command. |
| CVE-2021-33813 | High | 2021-06-16 | Protected by Waratek | No public exploit | An XXE issue in SAXBuilder in JDOM through 2.0.6 allows attackers to cause a denial of service via a crafted HTTP request. |
| CVE-2021-29428 | High | 2021-04-13 | No exploit published | No public exploit | In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. Gradle builds could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. This vulnerability impacted builds using precompiled script plugins written in Kotlin DSL and tests for Gradle plugins written using ProjectBuilder or TestKit. If you are on Windows or modern versions of macOS, you are not vulnerable. If you are on a Unix-like operating system with the "sticky" bit set on your system temporary directory, you are not vulnerable. The problem has been patched and released with Gradle 7.0. As a workaround, on Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. If you are unable to change the permissions of the system temporary directory, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only. For additional details refer to the referenced GitHub Security Advisory. |
| CVE-2021-29429 | Medium | 2021-04-12 | No exploit published | No public exploit | In Gradle before version 7.0, files created with open permissions in the system temporary directory can allow an attacker to access information downloaded by Gradle. Some builds could be vulnerable to a local information disclosure. Remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. Sensitive information contained in these files can be exposed to other local users on the same system. If you do not use the `TextResourceFactory` API, you are not vulnerable. As of Gradle 7.0, uses of the system temporary directory have been moved to the Gradle User Home directory. By default, this directory is restricted to the user running the build. As a workaround, set a more restrictive umask that removes read access to other users. When files are created in the system temporary directory, they will not be accessible to other users. If you are unable to change your system's umask, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only. |
| CVE-2021-23926 | Critical | 2021-01-14 | Protected by Waratek | No public exploit | The XML parsers used by XMLBeans up to version 2.6.0 did not set the properties needed to protect the user from malicious XML input. Vulnerabilities include possibilities for XML Entity Expansion attacks. Affects XMLBeans up to and including v2.6.0. |
| CVE-2020-13956 | Medium | 2020-12-02 | Outside Waratek scope | No public exploit | Apache HttpClient versions prior to version 4.5.13 and 5.0.3 can misinterpret malformed authority component in request URIs passed to the library as java.net.URI object and pick the wrong target host for request execution. |
| CVE-2020-7760 | High | 2020-10-30 | No exploit published | No public exploit | This affects the package codemirror before 5.58.2; the package org.apache.marmotta.webjars:codemirror before 5.58.2. The vulnerable regular expression is located in https://github.com/codemirror/CodeMirror/blob/cdb228ac736369c685865b122b736cd0d397836c/mode/javascript/javascript.jsL129. The ReDOS vulnerability of the regex is mainly due to the sub-pattern (s|/*.*?*/)* |
| CVE-2020-11979 | High | 2020-10-01 | No exploit published | No public exploit | As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the permissions of temporary files it created so that only the current user was allowed to access them. Unfortunately the fixcrlf task deleted the temporary file and created a new one without said protection, effectively nullifying the effort. This would still allow an attacker to inject modified source files into the build process. |
| CVE-2020-2849 | High | 2020-04-15 | No exploit published | No public exploit | Vulnerability in the Oracle Depot Repair product of Oracle E-Business Suite (component: Estimate and Actual Charges). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Depot Repair. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Depot Repair, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Depot Repair accessible data as well as unauthorized update, insert or delete access to some of Oracle Depot Repair accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N). |
| CVE-2019-12415 | Medium | 2019-10-23 | Protected by Waratek | No public exploit | In Apache POI up to 4.1.0, when using the tool XSSFExportToXml to convert user-provided Microsoft Excel documents, a specially crafted document can allow an attacker to read files from the local filesystem or from internal network resources via XML External Entity (XXE) Processing. |
| CVE-2019-16370 | Medium | 2019-09-16 | No exploit published | No public exploit | The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one that has the same SHA-1 message digest, a related issue to CVE-2005-4900. |
| CVE-2019-15052 | Critical | 2019-08-14 | Not applicable | No public exploit | The HTTP client in Gradle before 5.6 sends authentication credentials originally destined for the configured host. If that host returns a 30x redirect, Gradle also sends those credentials to all subsequent hosts that the request redirects to. This is similar to CVE-2018-1000007. |
| CVE-2019-11065 | Medium | 2019-04-10 | Not applicable | No public exploit | Gradle versions from 1.4 to 5.3.1 use an insecure HTTP URL to download dependencies when the built-in JavaScript or CoffeeScript Gradle plugins are used. Dependency artifacts could have been maliciously compromised by a MITM attack against the ajax.googleapis.com web site. |