Oracle Critical Patch Update January 2026
Released January 2026 · Oracle's advisory ↗ · ← Critical Patch Update, October 2025 · Critical Patch Update, April 2026 →
219 CVEs in this release, one square each
By status
15Protected by Waratek2Mitigation candidate58No exploit published14Outside Waratek scope130Not applicable
6Exploited, marked by the ring
No exploit published. For 26 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 10 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
10matches
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
10
100.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
10
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
2
20.0%
Forecast only
0
0.0%
No public exploit
8
80.0%
split by
peak 3 / month
Oct 241
No exploit published1
Medium1
not blocked1
No public exploit1
Nov 240
Dec 240
Jan 250
Feb 251
No exploit published1
Medium1
not blocked1
Proof of concept only1
Mar 250
Apr 250
May 250
Jun 251
No exploit published1
Medium1
not blocked1
No public exploit1
Jul 253
No exploit published3
Medium3
not blocked3
No public exploit3
Aug 251
No exploit published1
Medium1
not blocked1
No public exploit1
Sep 251
No exploit published1
Medium1
not blocked1
Proof of concept only1
Oct 251
No exploit published1
Medium1
not blocked1
No public exploit1
Nov 250
Dec 251
No exploit published1
Medium1
not blocked1
No public exploit1
Oct 24Dec 24Feb 25Apr 25Jun 25Aug 25Oct 25Dec 25
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2025-68161 | Medium | 2025-12-18 | No exploit published | No public exploit | The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName configuration attribute or the log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName system property is set to true. This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: * The attacker is able to intercept or redirect network traffic between the client and the log receiver. * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. |
| CVE-2025-61795 | Medium | 2025-10-27 | No exploit published | No public exploit | Improper Resource Shutdown or Release vulnerability in Apache Tomcat. If an error occurred (including exceeding limits) during the processing of a multipart upload, temporary copies of the uploaded parts written to disc were not cleaned up immediately but left for the garbage collection process to delete. Depending on JVM settings, application memory usage and application load, it was possible that space for the temporary copies of uploaded parts would be filled faster than GC cleared it, leading to a DoS. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.11, from 10.1.0-M1 through 10.1.46, from 9.0.0.M1 through 9.0.109. The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions may also be affected. Users are recommended to upgrade to version 11.0.12 or later, 10.1.47 or later or 9.0.110 or later which fixes the issue. |
| CVE-2025-58057 | Medium | 2025-09-04 | No exploit published | Proof of concept only | Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In netty-codec-compression versions 4.1.124.Final and below, and netty-codec versions 4.2.4.Final and below, when supplied with specially crafted input, BrotliDecoder and certain other decompression decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. BrotliDecoder.decompress has no limit in how often it calls pull, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is fixed in versions 4.1.125.Final of netty-codec and 4.2.5.Final of netty-codec-compression. |
| CVE-2025-8916 | Medium | 2025-08-13 | No exploit published | No public exploit | Allocation of Resources Without Limits or Throttling vulnerability in Legion of the Bouncy Castle Inc. BC Java bcpkix on All (API modules), Legion of the Bouncy Castle Inc. BC Java bcprov on All (API modules), Legion of the Bouncy Castle Inc. BCPKIX FIPS bcpkix-fips on All (API modules) allows Excessive Allocation. This vulnerability is associated with program files https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertPathReviewer.Java, https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathReviewer.Java. This issue affects BC Java: from 1.44 through 1.78; BC Java: from 1.44 through 1.78; BCPKIX FIPS: from 1.0.0 through 1.0.7, from 2.0.0 through 2.0.7. |
| CVE-2025-7962 | Medium | 2025-07-21 | No exploit published | No public exploit | In Jakarta Mail versions prior to 2.0.2 it is possible to perform an SMTP Injection by utilizing the \r and \n UTF-8 characters to separate different messages. |
| CVE-2025-48795 | Medium | 2025-07-15 | No exploit published | No public exploit | Apache CXF stores large stream based messages as temporary files on the local filesystem. A bug was introduced which means that the entire temporary file is read into memory and then logged. An attacker might be able to exploit this to cause a denial of service attack by causing an out of memory exception. In addition, it is possible to configure CXF to encrypt temporary files to prevent sensitive credentials from being cached unencrypted on the local filesystem, however this bug means that the cached files are written out to logs unencrypted. Users are recommended to upgrade to versions 3.5.11, 3.6.6, 4.0.7 or 4.1.1, which fixes this issue. |
| CVE-2025-48924 | Medium | 2025-07-11 | No exploit published | No public exploit | Uncontrolled Recursion vulnerability in Apache Commons Lang. This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. Users are recommended to upgrade to version 3.18.0, which fixes the issue. |
| CVE-2025-41234 | Medium | 2025-06-12 | No exploit published | No public exploit | Description In Spring Framework, versions 6.0.x as of 6.0.5, versions 6.1.x and 6.2.x, an application is vulnerable to a reflected file download (RFD) attack when it sets a “Content-Disposition” header with a non-ASCII charset, where the filename attribute is derived from user-supplied input. Specifically, an application is vulnerable when all the following are true: * The header is prepared with org.springframework.http.ContentDisposition. * The filename is set via ContentDisposition.Builder#filename(String, Charset). * The value for the filename is derived from user-supplied input. * The application does not sanitize the user-supplied input. * The downloaded content of the response is injected with malicious commands by the attacker (see RFD paper reference for details). An application is not vulnerable if any of the following is true: * The application does not set a “Content-Disposition” response header. * The header is not prepared with org.springframework.http.ContentDisposition. * The filename is set via one of: * ContentDisposition.Builder#filename(String), or * ContentDisposition.Builder#filename(String, ASCII) * The filename is not derived from user-supplied input. * The filename is derived from user-supplied input but sanitized by the application. * The attacker cannot inject malicious content in the downloaded content of the response. Affected Spring Products and VersionsSpring Framework: * 6.2.0 - 6.2.7 * 6.1.0 - 6.1.20 * 6.0.5 - 6.0.28 * Older, unsupported versions are not affected MitigationUsers of affected versions should upgrade to the corresponding fixed version. Affected version(s)Fix versionAvailability6.2.x6.2.8OSS6.1.x6.1.21OSS6.0.x6.0.29 Commercial https://enterprise.spring.io/ No further mitigation steps are necessary. CWE-113 in `Content-Disposition` handling in VMware Spring Framework versions 6.0.5 to 6.2.7 allows remote attackers to launch Reflected File Download (RFD) attacks via unsanitized user input in `ContentDisposition.Builder#filename(String, Charset)` with non-ASCII charsets. |
| CVE-2025-25193 | Medium | 2025-02-10 | No exploit published | Proof of concept only | Netty, an asynchronous, event-driven network application framework, has a vulnerability in versions up to and including 4.1.118.Final. An unsafe reading of environment file could potentially cause a denial of service in Netty. When loaded on an Windows application, Netty attempts to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. A similar issue was previously reported as CVE-2024-47535. This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. Commit d1fbda62d3a47835d3fb35db8bd42ecc205a5386 contains an updated fix. |
| CVE-2024-47554 | Medium | 2024-10-03 | No exploit published | No public exploit | Uncontrolled Resource Consumption vulnerability in Apache Commons IO. The org.apache.commons.io.input.XmlStreamReader class may excessively consume CPU resources when processing maliciously crafted input. This issue affects Apache Commons IO: from 2.0 before 2.14.0. Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue. |