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 30 matches · 4 protected · 3 exploited · 1 CISA KEV · 5 public PoC · 2 EPSS ≥ 0.5
Protected by Waratek
4
13.3%
Rule in development
0
0.0%
Mitigation candidate
3
10.0%
No exploit published
23
76.7%
blocked by ARMR today
4
13.3%
partly blocked
0
0.0%
not blocked
26
86.7%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
3
10.0%
Working exploit published
0
0.0%
Proof of concept only
4
13.3%
Forecast only
0
0.0%
No public exploit
23
76.7%
split by
peak 8 / quarter
Q1 222
Protected by Waratek1
No exploit published1
Critical1
Medium1
blocked by ARMR today1
not blocked1
Proof of concept only1
No public exploit1
Q2 220
Q3 220
Q4 220
Q1 230
Q2 232
No exploit published2
High1
Medium1
not blocked2
No public exploit2
Q3 233
Protected by Waratek1
No exploit published2
High1
Medium2
blocked by ARMR today1
not blocked2
No public exploit3
Q4 235
Mitigation candidate1
No exploit published4
Critical1
High2
Medium2
not blocked5
Exploited1
No public exploit4
Q1 248
Mitigation candidate1
No exploit published7
High4
Medium4
not blocked8
Proof of concept only3
No public exploit5
Q2 242
Protected by Waratek1
Mitigation candidate1
High2
blocked by ARMR today1
not blocked1
Exploited1
No public exploit1
Q3 245
Protected by Waratek1
No exploit published4
High5
blocked by ARMR today1
not blocked4
Exploited1
No public exploit4
Q4 243
No exploit published3
High2
Medium1
not blocked3
No public exploit3
Q1 22Q2 22Q3 22Q4 22Q1 23Q2 23Q3 23Q4 23Q1 24Q2 24Q3 24Q4 24
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2024-21285 | High | 2024-10-15 | No exploit published | No public exploit | Vulnerability in the Oracle Banking Liquidity Management product of Oracle Financial Services Applications (component: Reports). The supported version that is affected is 14.5.0.12.0. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Banking Liquidity Management. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of Oracle Banking Liquidity Management. CVSS 3.1 Base Score 7.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H). |
| CVE-2024-21284 | High | 2024-10-15 | No exploit published | No public exploit | Vulnerability in the Oracle Banking Liquidity Management product of Oracle Financial Services Applications (component: Reports). The supported version that is affected is 14.5.0.12.0. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Banking Liquidity Management. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of Oracle Banking Liquidity Management. CVSS 3.1 Base Score 7.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H). |
| CVE-2024-21281 | Medium | 2024-10-15 | No exploit published | No public exploit | Vulnerability in the Oracle Banking Liquidity Management product of Oracle Financial Services Applications (component: Infrastructure). The supported version that is affected is 14.7.0.6.0. Difficult to exploit vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle Banking Liquidity Management. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Banking Liquidity Management accessible data as well as unauthorized read access to a subset of Oracle Banking Liquidity Management accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Banking Liquidity Management. CVSS 3.1 Base Score 5.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:H/A:L). |
| CVE-2024-7254 | High | 2024-09-19 | No exploit published | No public exploit | Any project that parses untrusted Protocol Buffers data containing an arbitrary number of nested groups / series of SGROUP tags can corrupted by exceeding the stack limit i.e. StackOverflow. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. |
| CVE-2024-38816 | High | 2024-09-13 | Protected by Waratek | Exploited | Applications serving static resources through the functional web frameworks WebMvc.fn or WebFlux.fn are vulnerable to path traversal attacks. An attacker can craft malicious HTTP requests and obtain any file on the file system that is also accessible to the process in which the Spring application is running. Specifically, an application is vulnerable when both of the following are true: * the web application uses RouterFunctions to serve static resources * resource handling is explicitly configured with a FileSystemResource location However, malicious requests are blocked and rejected when any of the following is true: * the Spring Security HTTP Firewall https://docs.spring.io/spring-security/reference/servlet/exploits/firewall.html is in use * the application runs on Tomcat or Jetty |
| CVE-2024-41172 | High | 2024-07-19 | No exploit published | No public exploit | In versions of Apache CXF before 3.6.4 and 4.0.5 (3.5.x and lower versions are not impacted), a CXF HTTP client conduit may prevent HTTPClient instances from being garbage collected and it is possible that memory consumption will continue to increase, eventually causing the application to run out of memory |
| CVE-2024-32007 | High | 2024-07-19 | No exploit published | No public exploit | An improper input validation of the p2c parameter in the Apache CXF JOSE code before 4.0.5, 3.6.4 and 3.5.9 allows an attacker to perform a denial of service attack by specifying a large value for this parameter in a token. |
| CVE-2024-34750 | High | 2024-07-03 | No exploit published | No public exploit | Improper Handling of Exceptional Conditions, Uncontrolled Resource Consumption vulnerability in Apache Tomcat. When processing an HTTP/2 stream, Tomcat did not handle some cases of excessive HTTP headers correctly. This led to a miscounting of active HTTP/2 streams which in turn led to the use of an incorrect infinite timeout which allowed connections to remain open which should have been closed. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M20, from 10.1.0-M1 through 10.1.24, from 9.0.0-M1 through 9.0.89. 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 EOL versions may also be affected. Users are recommended to upgrade to version 11.0.0-M21, 10.1.25 or 9.0.90, which fixes the issue. |
| CVE-2024-32114 | High | 2024-05-02 | Mitigation candidate | Exploited | In Apache ActiveMQ 6.x, the default configuration doesn't secure the API web context (where the Jolokia JMX REST API and the Message REST API are located). It means that anyone can use these layers without any required authentication. Potentially, anyone can interact with the broker (using Jolokia JMX REST API) and/or produce/consume messages or purge/delete destinations (using the Message REST API). To mitigate, users can update the default conf/jetty.xml configuration file to add authentication requirement: <bean id="securityConstraintMapping" class="org.eclipse.jetty.security.ConstraintMapping"> <property name="constraint" ref="securityConstraint" /> <property name="pathSpec" value="/" /> </bean> Or we encourage users to upgrade to Apache ActiveMQ 6.1.2 where the default configuration has been updated with authentication by default. |
| CVE-2024-22262 | High | 2024-04-16 | Protected by Waratek | No public exploit | Applications that use UriComponentsBuilder to parse an externally provided URL (e.g. through a query parameter) AND perform validation checks on the host of the parsed URL may be vulnerable to a open redirect https://cwe.mitre.org/data/definitions/601.html attack or to a SSRF attack if the URL is used after passing validation checks. This is the same as CVE-2024-22259 https://spring.io/security/cve-2024-22259 and CVE-2024-22243 https://spring.io/security/cve-2024-22243 , but with different input. |
| CVE-2024-29025 | Medium | 2024-03-25 | 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. The `HttpPostRequestDecoder` can be tricked to accumulate data. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits. This vulnerability is fixed in 4.1.108.Final. |
| CVE-2024-29133 | Medium | 2024-03-21 | No exploit published | No public exploit | Out-of-bounds Write vulnerability in Apache Commons Configuration.This issue affects Apache Commons Configuration: from 2.0 before 2.10.1. Users are recommended to upgrade to version 2.10.1, which fixes the issue. |
| CVE-2024-29131 | High | 2024-03-21 | No exploit published | No public exploit | Out-of-bounds Write vulnerability in Apache Commons Configuration.This issue affects Apache Commons Configuration: from 2.0 before 2.10.1. Users are recommended to upgrade to version 2.10.1, which fixes the issue. |
| CVE-2024-24549 | High | 2024-03-13 | Mitigation candidate | Proof of concept only | Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98. Other, older, EOL versions may also be affected. Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue. |
| CVE-2024-22201 | High | 2024-02-26 | No exploit published | Proof of concept only | Jetty is a Java based web server and servlet engine. An HTTP/2 SSL connection that is established and TCP congested will be leaked when it times out. An attacker can cause many connections to end up in this state, and the server may run out of file descriptors, eventually causing the server to stop accepting new connections from valid clients. The vulnerability is patched in 9.4.54, 10.0.20, 11.0.20, and 12.0.6. |
| CVE-2024-26308 | Medium | 2024-02-19 | No exploit published | No public exploit | Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress.This issue affects Apache Commons Compress: from 1.21 before 1.26. Users are recommended to upgrade to version 1.26, which fixes the issue. |
| CVE-2024-25710 | High | 2024-02-19 | No exploit published | No public exploit | Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress.This issue affects Apache Commons Compress: from 1.3 through 1.25.0. Users are recommended to upgrade to version 1.26.0 which fixes the issue. |
| CVE-2024-23635 | Medium | 2024-02-02 | No exploit published | No public exploit | AntiSamy is a library for performing fast, configurable cleansing of HTML coming from untrusted sources. Prior to 1.7.5, there is a potential for a mutation XSS (mXSS) vulnerability in AntiSamy caused by flawed parsing of the HTML being sanitized. To be subject to this vulnerability the `preserveComments` directive must be enabled in your policy file. As a result, certain crafty inputs can result in elements in comment tags being interpreted as executable when using AntiSamy's sanitized output. Patched in AntiSamy 1.7.5 and later. |
| CVE-2023-34055 | Medium | 2023-11-28 | No exploit published | No public exploit | In Spring Boot versions 2.7.0 - 2.7.17, 3.0.0-3.0.12 and 3.1.0-3.1.5, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition. Specifically, an application is vulnerable when all of the following are true: * the application uses Spring MVC or Spring WebFlux * org.springframework.boot:spring-boot-actuator is on the classpath |
| CVE-2022-46337 | Critical | 2023-11-20 | No exploit published | No public exploit | A cleverly devised username might bypass LDAP authentication checks. In LDAP-authenticated Derby installations, this could let an attacker fill up the disk by creating junk Derby databases. In LDAP-authenticated Derby installations, this could also allow the attacker to execute malware which was visible to and executable by the account which booted the Derby server. In LDAP-protected databases which weren't also protected by SQL GRANT/REVOKE authorization, this vulnerability could also let an attacker view and corrupt sensitive data and run sensitive database functions and procedures. Mitigation: Users should upgrade to Java 21 and Derby 10.17.1.0. Alternatively, users who wish to remain on older Java versions should build their own Derby distribution from one of the release families to which the fix was backported: 10.16, 10.15, and 10.14. Those are the releases which correspond, respectively, with Java LTS versions 17, 11, and 8. |
| 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-5072 | High | 2023-10-12 | No exploit published | No public exploit | Denial of Service in JSON-Java versions up to and including 20230618. A bug in the parser means that an input string of modest size can lead to indefinite amounts of memory being used. |
| CVE-2023-44487 | High | 2023-10-10 | Mitigation candidate | Exploited | The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. |
| CVE-2023-39410 | High | 2023-09-29 | Protected by Waratek | No public exploit | When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2. Users should update to apache-avro version 1.11.3 which addresses this issue. |
| CVE-2023-42503 | Medium | 2023-09-14 | No exploit published | No public exploit | Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. Users are recommended to upgrade to version 1.24.0, which fixes the issue. A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. [1]: https://issues.apache.org/jira/browse/COMPRESS-612 [2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 [3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html [4]: https://bugs.openjdk.org/browse/JDK-6560193 [5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. |
| CVE-2023-33201 | Medium | 2023-07-05 | No exploit published | No public exploit | Bouncy Castle For Java before 1.74 is affected by an LDAP injection vulnerability. The vulnerability only affects applications that use an LDAP CertStore from Bouncy Castle to validate X.509 certificates. During the certificate validation process, Bouncy Castle inserts the certificate's Subject Name into an LDAP search filter without any escaping, which leads to an LDAP injection vulnerability. |
| CVE-2023-2976 | High | 2023-06-14 | No exploit published | No public exploit | Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. |
| CVE-2023-20863 | Medium | 2023-04-13 | No exploit published | No public exploit | In spring framework versions prior to 5.2.24 release+ ,5.3.27+ and 6.0.8+ , it is possible for a user to provide a specially crafted SpEL expression that may cause a denial-of-service (DoS) condition. |
| CVE-2022-23437 | Medium | 2022-01-24 | No exploit published | No public exploit | There's a vulnerability within the Apache Xerces Java (XercesJ) XML parser when handling specially crafted XML document payloads. This causes, the XercesJ XML parser to wait in an infinite loop, which may sometimes consume system resources for prolonged duration. This vulnerability is present within XercesJ version 2.12.1 and the previous versions. |
| CVE-2022-23305 | Critical | 2022-01-18 | Protected by Waratek | Proof of concept only | By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. 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. |