Oracle Commerce CVEs with a working exploit
4 CVEs, 3 protected by Waratek
Overview 4 matches · 3 protected · 0 exploited · 0 CISA KEV · 3 EPSS ≥ 0.5
Protected by Waratek
3
75.0%
Rule in development
0
0.0%
Mitigation candidate
1
25.0%
No exploit published
0
0.0%
blocked by ARMR today
3
75.0%
partly blocked
0
0.0%
not blocked
1
25.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
4
100.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
0
0.0%
split by
peak 1 / quarter
Q3 201
Mitigation candidate1
High1
not blocked1
Working exploit published1
Q4 200
Q1 210
Q2 210
Q3 210
Q4 210
Q1 220
Q2 220
Q3 220
Q4 220
Q1 230
Q2 230
Q3 230
Q4 230
Q1 240
Q2 240
Q3 240
Q4 241
Protected by Waratek1
High1
blocked by ARMR today1
Working exploit published1
Q1 250
Q2 250
Q3 251
Protected by Waratek1
Medium1
blocked by ARMR today1
Working exploit published1
Q4 251
Protected by Waratek1
Critical1
blocked by ARMR today1
Working exploit published1
Q4 20Q2 21Q4 21Q2 22Q4 22Q2 23Q4 23Q2 24Q4 24Q2 25Q4 25
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| 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-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-2024-38819 | High | 2024-12-19 | Protected by Waratek | Working exploit published | 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. |
| CVE-2020-13935 | High | 2020-07-14 | Mitigation candidate | Working exploit published | The payload length in a WebSocket frame was not correctly validated in Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M1 to 9.0.36, 8.5.0 to 8.5.56 and 7.0.27 to 7.0.104. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service. |