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 28 matches · 7 protected · 1 exploited · 0 CISA KEV · 5 public PoC · 2 EPSS ≥ 0.5
Protected by Waratek
7
25.0%
Rule in development
0
0.0%
Mitigation candidate
1
3.6%
No exploit published
20
71.4%
blocked by ARMR today
7
25.0%
partly blocked
0
0.0%
not blocked
21
75.0%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 11 / quarter
Q2 201
Protected by Waratek1
Critical1
blocked by ARMR today1
No public exploit1
Q3 200
Q4 200
Q1 210
Q2 210
Q3 210
Q4 211
Protected by Waratek1
Medium1
blocked by ARMR today1
Exploited1
Q1 220
Q2 220
Q3 220
Q4 221
Protected by Waratek1
Critical1
blocked by ARMR today1
Proof of concept only1
Q1 230
Q2 230
Q3 230
Q4 230
Q1 240
Q2 240
Q3 240
Q4 242
Protected by Waratek1
No exploit published1
Critical1
Medium1
blocked by ARMR today1
not blocked1
No public exploit2
Q1 251
No exploit published1
Medium1
not blocked1
Proof of concept only1
Q2 256
Protected by Waratek1
Mitigation candidate1
No exploit published4
Critical1
High2
Medium2
Low1
blocked by ARMR today1
not blocked5
Working exploit published1
Proof of concept only2
No public exploit3
Q3 2511
Protected by Waratek1
No exploit published10
High4
Medium6
Low1
blocked by ARMR today1
not blocked10
Working exploit published1
Proof of concept only1
No public exploit9
Q4 255
Protected by Waratek1
No exploit published4
Critical2
High1
Medium2
blocked by ARMR today1
not blocked4
Working exploit published1
No public exploit4
Q2 20Q4 20Q2 21Q4 21Q2 22Q4 22Q2 23Q4 23Q2 24Q4 24Q2 25Q4 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-66566 | High | 2025-12-05 | No exploit published | No public exploit | yawkat LZ4 Java provides LZ4 compression for Java. Insufficient clearing of the output buffer in Java-based decompressor implementations in lz4-java 1.10.0 and earlier allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data. JNI-based implementations are not affected. This vulnerability is fixed in 1.10.1. |
| CVE-2025-66516 | Critical | 2025-12-04 | Protected by Waratek | Working exploit published | Critical XXE in Apache Tika tika-core (1.13-3.2.1), tika-pdf-module (2.0.0-3.2.1) and tika-parsers (1.13-1.28.5) modules on all platforms allows an attacker to carry out XML External Entity injection via a crafted XFA file inside of a PDF. This CVE covers the same vulnerability as in CVE-2025-54988. However, this CVE expands the scope of affected packages in two ways. First, while the entrypoint for the vulnerability was the tika-parser-pdf-module as reported in CVE-2025-54988, the vulnerability and its fix were in tika-core. Users who upgraded the tika-parser-pdf-module but did not upgrade tika-core to >= 3.2.2 would still be vulnerable. Second, the original report failed to mention that in the 1.x Tika releases, the PDFParser was in the "org.apache.tika:tika-parsers" module. |
| CVE-2025-12383 | Critical | 2025-11-18 | No exploit published | No public exploit | In Eclipse Jersey versions 2.45, 3.0.16, 3.1.9 a race condition can cause ignoring of critical SSL configurations - such as mutual authentication, custom key/trust stores, and other security settings. This issue may result in SSLHandshakeException under normal circumstances, but under certain conditions, it could lead to unauthorized trust in insecure servers (see PoC) |
| 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-41249 | High | 2025-09-16 | No exploit published | No public exploit | The Spring Framework annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue if such annotations are used for authorization decisions. Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature. You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces. This CVE is published in conjunction with CVE-2025-41248 https://spring.io/security/cve-2025-41248 . |
| CVE-2025-41248 | High | 2025-09-16 | No exploit published | No public exploit | The Spring Security annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue when using @PreAuthorize and other method security annotations, resulting in an authorization bypass. Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature. You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces. This CVE is published in conjunction with CVE-2025-41249 https://spring.io/security/cve-2025-41249 . |
| 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-58056 | Low | 2025-09-03 | No exploit published | No public exploit | Netty is an asynchronous event-driven network application framework for development of maintainable high performance protocol servers and clients. In versions 4.1.124.Final, and 4.2.0.Alpha3 through 4.2.4.Final, Netty incorrectly accepts standalone newline characters (LF) as a chunk-size line terminator, regardless of a preceding carriage return (CR), instead of requiring CRLF per HTTP/1.1 standards. When combined with reverse proxies that parse LF differently (treating it as part of the chunk extension), attackers can craft requests that the proxy sees as one request but Netty processes as two, enabling request smuggling attacks. This is fixed in versions 4.1.125.Final and 4.2.5.Final. |
| CVE-2025-5115 | High | 2025-08-20 | No exploit published | No public exploit | In Eclipse Jetty, versions <=9.4.57, <=10.0.25, <=11.0.25, <=12.0.21, <=12.1.0.alpha2, an HTTP/2 client may trigger the server to send RST_STREAM frames, for example by sending frames that are malformed or that should not be sent in a particular stream state, therefore forcing the server to consume resources such as CPU and memory. For example, a client can open a stream and then send WINDOW_UPDATE frames with window size increment of 0, which is illegal. Per specification https://www.rfc-editor.org/rfc/rfc9113.html#name-window_update , the server should send a RST_STREAM frame. The client can now open another stream and send another bad WINDOW_UPDATE, therefore causing the server to consume more resources than necessary, as this case does not exceed the max number of concurrent streams, yet the client is able to create an enormous amount of streams in a short period of time. The attack can be performed with other conditions (for example, a DATA frame for a closed stream) that cause the server to send a RST_STREAM frame. Links: * https://github.com/jetty/jetty.project/security/advisories/GHSA-mmxm-8w33-wc4h |
| CVE-2025-41242 | Medium | 2025-08-18 | Protected by Waratek | Working exploit published | Spring Framework MVC applications can be vulnerable to a “Path Traversal Vulnerability” when deployed on a non-compliant Servlet container. An application can be vulnerable when all the following are true: * the application is deployed as a WAR or with an embedded Servlet container * the Servlet container does not reject suspicious sequences https://jakarta.ee/specifications/servlet/6.1/jakarta-servlet-spec-6.1.html#uri-path-canonicalization * the application serves static resources https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-config/static-resources.html#page-title with Spring resource handling We have verified that applications deployed on Apache Tomcat or Eclipse Jetty are not vulnerable, as long as default security features are not disabled in the configuration. Because we cannot check exploits against all Servlet containers and configuration variants, we strongly recommend upgrading your application. |
| 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-48989 | High | 2025-08-13 | No exploit published | No public exploit | Improper Resource Shutdown or Release vulnerability in Apache Tomcat made Tomcat vulnerable to the made you reset attack. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.9, from 10.1.0-M1 through 10.1.43 and from 9.0.0.M1 through 9.0.107. Older, EOL versions may also be affected. Users are recommended to upgrade to one of versions 11.0.10, 10.1.44 or 9.0.108 which fix the issue. |
| 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-48976 | High | 2025-06-16 | No exploit published | No public exploit | Allocation of resources for multipart headers with insufficient limits enabled a DoS vulnerability in Apache Commons FileUpload. This issue affects Apache Commons FileUpload: from 1.0 before 1.6; from 2.0.0-M1 before 2.0.0-M4. Users are recommended to upgrade to versions 1.6 or 2.0.0-M4, which fix 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-48734 | High | 2025-05-28 | No exploit published | Proof of concept only | Improper Access Control vulnerability in Apache Commons. A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. Users of the artifact org.apache.commons:commons-beanutils2 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. |
| CVE-2025-22233 | Low | 2025-05-16 | No exploit published | No public exploit | CVE-2024-38820 ensured Locale-independent, lowercase conversion for both the configured disallowedFields patterns and for request parameter names. However, there are still cases where it is possible to bypass the disallowedFields checks. Affected Spring Products and Versions Spring Framework: * 6.2.0 - 6.2.6 * 6.1.0 - 6.1.19 * 6.0.0 - 6.0.27 * 5.3.0 - 5.3.42 * Older, unsupported versions are also affected Mitigation Users of affected versions should upgrade to the corresponding fixed version. Affected version(s)Fix Version Availability 6.2.x 6.2.7 OSS6.1.x 6.1.20 OSS6.0.x 6.0.28 Commercial https://enterprise.spring.io/ 5.3.x 5.3.43 Commercial https://enterprise.spring.io/ No further mitigation steps are necessary. Generally, we recommend using a dedicated model object with properties only for data binding, or using constructor binding since constructor arguments explicitly declare what to bind together with turning off setter binding through the declarativeBinding flag. See the Model Design section in the reference documentation. For setting binding, prefer the use of allowedFields (an explicit list) over disallowedFields. Credit This issue was responsibly reported by the TERASOLUNA Framework Development Team from NTT DATA Group Corporation. |
| CVE-2025-27533 | Medium | 2025-05-07 | Mitigation candidate | Working exploit published | Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ. During unmarshalling of OpenWire commands the size value of buffers was not properly validated which could lead to excessive memory allocation and be exploited to cause a denial of service (DoS) by depleting process memory, thereby affecting applications and services that rely on the availability of the ActiveMQ broker when not using mutual TLS connections. This issue affects Apache ActiveMQ: from 6.0.0 before 6.1.6, from 5.18.0 before 5.18.7, from 5.17.0 before 5.17.7, before 5.16.8. ActiveMQ 5.19.0 is not affected. Users are recommended to upgrade to version 6.1.6+, 5.19.0+, 5.18.7+, 5.17.7, or 5.16.8 or which fixes the issue. Existing users may implement mutual TLS to mitigate the risk on affected brokers. |
| CVE-2025-30065 | Critical | 2025-04-01 | Protected by Waratek | Proof of concept only | Schema parsing in the parquet-avro module of Apache Parquet 1.15.0 and previous versions allows bad actors to execute arbitrary code Users are recommended to upgrade to version 1.15.1, which fixes the issue. |
| 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-52046 | Critical | 2024-12-25 | Protected by Waratek | No public exploit | The ObjectSerializationDecoder in Apache MINA uses Java’s native deserialization protocol to process incoming serialized data but lacks the necessary security checks and defenses. This vulnerability allows attackers to exploit the deserialization process by sending specially crafted malicious serialized data, potentially leading to remote code execution (RCE) attacks. This issue affects MINA core versions 2.0.X, 2.1.X and 2.2.X, and will be fixed by the releases 2.0.27, 2.1.10 and 2.2.4. It's also important to note that an application using MINA core library will only be affected if the IoBuffer#getObject() method is called, and this specific method is potentially called when adding a ProtocolCodecFilter instance using the ObjectSerializationCodecFactory class in the filter chain. If your application is specifically using those classes, you have to upgrade to the latest version of MINA core library. Upgrading will not be enough: you also need to explicitly allow the classes the decoder will accept in the ObjectSerializationDecoder instance, using one of the three new methods: /** * Accept class names where the supplied ClassNameMatcher matches for * deserialization, unless they are otherwise rejected. * * @param classNameMatcher the matcher to use */ public void accept(ClassNameMatcher classNameMatcher) /** * Accept class names that match the supplied pattern for * deserialization, unless they are otherwise rejected. * * @param pattern standard Java regexp */ public void accept(Pattern pattern) /** * Accept the wildcard specified classes for deserialization, * unless they are otherwise rejected. * * @param patterns Wildcard file name patterns as defined by * {@link org.apache.commons.io.FilenameUtils#wildcardMatch(String, String) FilenameUtils.wildcardMatch} */ public void accept(String... patterns) By default, the decoder will reject *all* classes that will be present in the incoming data. Note: The FtpServer, SSHd and Vysper sub-project are not affected by this issue. |
| 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. |
| CVE-2022-45047 | Critical | 2022-11-16 | Protected by Waratek | Proof of concept only | Class org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider in Apache MINA SSHD <= 2.9.1 uses Java deserialization to load a serialized java.security.PrivateKey. The class is one of several implementations that an implementor using Apache MINA SSHD can choose for loading the host keys of an SSH server. |
| CVE-2021-45105 | Medium | 2021-12-18 | Protected by Waratek | Exploited | Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0, 2.12.3, and 2.3.1. |
| CVE-2020-10683 | Critical | 2020-05-01 | Protected by Waratek | No public exploit | dom4j before 2.0.3 and 2.1.x before 2.1.3 allows external DTDs and External Entities by default, which might enable XXE attacks. However, there is popular external documentation from OWASP showing how to enable the safe, non-default behavior in any application that uses dom4j. |