Oracle Critical Patch Update October 2025
Released October 2025 · Oracle's advisory ↗ · ← Critical Patch Update, July 2025 · Critical Patch Update, January 2026 →
234 CVEs in this release, one square each
By status
13Protected by Waratek5Mitigation candidate77No exploit published15Outside Waratek scope124Not applicable
7Exploited, marked by the ring
No exploit published. For 36 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 118 matches · 51 in Waratek scope · 3 protected · 1 exploited · 0 CISA KEV · 2 public PoC · 1 EPSS ≥ 0.5
118matches
51in Waratek scope43.2%
3protected2.5%
1exploited0.8%
0CISA KEV0.0%
2public PoC1.7%
1EPSS ≥ 0.50.8%
Protected by Waratek
3
2.5%
Rule in development
0
0.0%
Mitigation candidate
2
1.7%
No exploit published
46
39.0%
Outside Waratek scope
4
3.4%
Not applicable
63
53.4%
Withdrawn CVE
0
0.0%
blocked by ARMR today
3
2.5%
partly blocked
0
0.0%
not blocked
115
97.5%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 50 / quarter
Q4 203
Protected by Waratek2
Outside Waratek scope1
Medium3
blocked by ARMR today2
not blocked1
No public exploit3
Q1 210
Q2 211
Not applicable1
Medium1
not blocked1
Proof of concept only1
Q3 210
Q4 210
Q1 221
No exploit published1
Medium1
not blocked1
No public exploit1
Q2 221
No exploit published1
Medium1
not blocked1
No public exploit1
Q3 220
Q4 220
Q1 230
Q2 235
Not applicable5
Medium5
not blocked5
Proof of concept only1
No public exploit4
Q3 230
Q4 231
No exploit published1
Medium1
not blocked1
No public exploit1
Q1 241
Outside Waratek scope1
Medium1
not blocked1
Proof of concept only1
Q2 242
Not applicable2
Medium2
not blocked2
Forecast only1
No public exploit1
Q3 244
No exploit published1
Not applicable3
Medium4
not blocked4
Proof of concept only1
No public exploit3
Q4 244
No exploit published3
Not applicable1
Medium4
not blocked4
No public exploit4
Q1 255
No exploit published2
Not applicable3
Medium5
not blocked5
Proof of concept only1
No public exploit4
Q2 2515
Protected by Waratek1
Mitigation candidate1
No exploit published2
Not applicable11
Medium15
blocked by ARMR today1
not blocked14
Working exploit published1
Proof of concept only4
No public exploit10
Q3 2525
Mitigation candidate1
No exploit published9
Not applicable15
Medium25
not blocked25
Exploited1
Proof of concept only2
No public exploit22
Q4 2550
No exploit published26
Outside Waratek scope2
Not applicable22
Medium50
not blocked50
No public exploit50
Q4 20Q2 21Q4 21Q2 22Q4 22Q2 23Q4 23Q2 24Q4 24Q2 25Q4 25
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2023-7256 | Medium | 2024-08-31 | Not applicable | No public exploit | In affected libpcap versions during the setup of a remote packet capture the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo(), but does not clearly indicate to the caller function whether freeaddrinfo() still remains to be called after the function returns. This makes it possible in some scenarios that both the function and its caller call freeaddrinfo() for the same allocated memory block. A similar problem was reported in Apple libpcap, to which Apple assigned CVE-2023-40400. |
| CVE-2024-41909 | Medium | 2024-08-12 | No exploit published | No public exploit | Like many other SSH implementations, Apache MINA SSHD suffered from the issue that is more widely known as CVE-2023-48795. An attacker that can intercept traffic between client and server could drop certain packets from the stream, potentially causing client and server to consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack The mitigations to prevent this type of attack were implemented in Apache MINA SSHD 2.12.0, both client and server side. Users are recommended to upgrade to at least this version. Note that both the client and the server implementation must have mitigations applied against this issue, otherwise the connection may still be affected. |
| CVE-2024-6923 | Medium | 2024-08-01 | Not applicable | Proof of concept only | There is a MEDIUM severity vulnerability affecting CPython. The email module didn’t properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized. |
| CVE-2024-35195 | Medium | 2024-05-20 | Not applicable | No public exploit | Requests is a HTTP library. Prior to 2.32.0, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. This vulnerability is fixed in 2.32.0. |
| CVE-2024-28182 | Medium | 2024-04-04 | Not applicable | Forecast only | nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. The nghttp2 library prior to version 1.61.0 keeps reading the unbounded number of HTTP/2 CONTINUATION frames even after a stream is reset to keep HPACK context in sync. This causes excessive CPU usage to decode HPACK stream. nghttp2 v1.61.0 mitigates this vulnerability by limiting the number of CONTINUATION frames it accepts per stream. There is no workaround for this vulnerability. |
| CVE-2024-26462 | Medium | 2024-02-29 | Outside Waratek scope | Proof of concept only | Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/kdc/ndr.c. |
| CVE-2023-44483 | Medium | 2023-10-20 | No exploit published | No public exploit | All versions of Apache Santuario - XML Security for Java prior to 2.2.6, 2.3.4, and 3.0.3, when using the JSR 105 API, are vulnerable to an issue where a private key may be disclosed in log files when generating an XML Signature and logging with debug level is enabled. Users are recommended to upgrade to version 2.2.6, 2.3.4, or 3.0.3, which fixes this issue. |
| CVE-2023-26555 | Medium | 2023-04-11 | Not applicable | No public exploit | praecis_parse in ntpd/refclock_palisade.c in NTP 4.2.8p15 has an out-of-bounds write. Any attack method would be complex, e.g., with a manipulated GPS receiver. |
| CVE-2023-26554 | Medium | 2023-04-11 | Not applicable | Proof of concept only | mstolfp in libntp/mstolfp.c in NTP 4.2.8p15 has an out-of-bounds write when adding a '\0' character. An adversary may be able to attack a client ntpq process, but cannot attack ntpd. |
| CVE-2023-26553 | Medium | 2023-04-11 | Not applicable | No public exploit | mstolfp in libntp/mstolfp.c in NTP 4.2.8p15 has an out-of-bounds write when copying the trailing number. An adversary may be able to attack a client ntpq process, but cannot attack ntpd. |
| CVE-2023-26552 | Medium | 2023-04-11 | Not applicable | No public exploit | mstolfp in libntp/mstolfp.c in NTP 4.2.8p15 has an out-of-bounds write when adding a decimal point. An adversary may be able to attack a client ntpq process, but cannot attack ntpd. |
| CVE-2023-26551 | Medium | 2023-04-11 | Not applicable | No public exploit | mstolfp in libntp/mstolfp.c in NTP 4.2.8p15 has an out-of-bounds write in the cp<cpdec while loop. An adversary may be able to attack a client ntpq process, but cannot attack ntpd. |
| CVE-2022-22968 | Medium | 2022-04-14 | No exploit published | No public exploit | In Spring Framework versions 5.3.0 - 5.3.18, 5.2.0 - 5.2.20, and older unsupported versions, the patterns for disallowedFields on a DataBinder are case sensitive which means a field is not effectively protected unless it is listed with both upper and lower case for the first character of the field, including upper and lower case for the first character of all nested fields within the property path. |
| CVE-2022-24329 | Medium | 2022-02-25 | No exploit published | No public exploit | In JetBrains Kotlin before 1.6.0, it was not possible to lock dependencies for Multiplatform Gradle Projects. |
| CVE-2021-22897 | Medium | 2021-06-11 | Not applicable | Proof of concept only | curl 7.61.0 through 7.76.1 suffers from exposure of data element to wrong session due to a mistake in the code for CURLOPT_SSL_CIPHER_LIST when libcurl is built to use the Schannel TLS library. The selected cipher set was stored in a single "static" variable in the library, which has the surprising side-effect that if an application sets up multiple concurrent transfers, the last one that sets the ciphers will accidentally control the set used by all transfers. In a worst-case scenario, this weakens transport security significantly. |
| 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-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-15250 | Medium | 2020-10-12 | Protected by Waratek | No public exploit | In JUnit4 from version 4.7 and before 4.13.1, the test rule TemporaryFolder contains a local information disclosure vulnerability. On Unix like systems, the system's temporary directory is shared between all users on that system. Because of this, when files and directories are written into this directory they are, by default, readable by other users on that same system. This vulnerability does not allow other users to overwrite the contents of these directories or files. This is purely an information disclosure vulnerability. This vulnerability impacts you if the JUnit tests write sensitive information, like API keys or passwords, into the temporary folder, and the JUnit tests execute in an environment where the OS has other untrusted users. Because certain JDK file system APIs were only added in JDK 1.7, this this fix is dependent upon the version of the JDK you are using. For Java 1.7 and higher users: this vulnerability is fixed in 4.13.1. For Java 1.6 and lower users: no patch is available, you must use the workaround below. If you are unable to patch, or are stuck running on Java 1.6, specifying the `java.io.tmpdir` system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability. For more information, including an example of vulnerable code, see the referenced GitHub Security Advisory. |