Cyber Resilience

CVE-2025-24813

RCE in Apache Tomcat ≤ 9.0.99

CISA KEVActive ExploitationEUVD ExploitedPublic PoCRCEDeserialization
Published
10 March 2025
Modified
23 October 2025
KEV Added
01 April 2025
Patch / advisory
CVSS Score v3.1 9.8
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score 0.99 100.0th percentile
Risk Priority 97 floored blend · peak EPSS

Summary

CVE-2025-24813 is a critical-severity Internal Dot (CWE-44) vulnerability in Apache Tomcat. Its CVSS base score is 9.8 (Critical).

Operationally, exploitation aligns with the MITRE ATT&CK technique Path Interception (T1034); ranked in the top 0.0% of CVEs by exploit likelihood; CISA has added it to the Known Exploited Vulnerabilities catalog; a public proof-of-concept is referenced.

The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-10 (Information Input Validation) — see the control section below for these in your framework.

Deeper analysis AI-assisted summary

Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.

Apache Tomcat's Default Servlet is vulnerable to a path equivalence flaw involving internal dots in filenames, which affects versions 11.0.0-M1 through 11.0.2, 10.1.0-M1 through 10.1.34, 9.0.0.M1 through 9.0.98, and several end-of-life releases including 8.5.0 through 8.5.100. The issue arises when the servlet permits writes and supports partial PUT requests, allowing crafted paths to bypass intended restrictions on file handling.

An unauthenticated remote attacker can exploit the flaw when the application uses file-based session persistence in the default location together with a deserializable library, achieving remote code execution. Under a narrower set of conditions involving subdirectories for public versus sensitive uploads and attacker knowledge of target filenames, the same vector can also be used to read security-sensitive files or inject malicious content into them via partial PUT operations.

Apache Tomcat project advisories and downstream distributors such as Debian and NetApp direct users to upgrade immediately to 11.0.3, 10.1.35, or 9.0.99. These releases contain the fix; no workarounds are specified beyond disabling writes on the Default Servlet or restricting partial PUT support where feasible.

The CVE carries a CVSS score of 9.8 and an EPSS value that has reached 0.94, indicating a high likelihood of exploitation in the wild.

OWASP Top 10 for Web (2025)

EU & UK References

Vulnerability Data

Path Equivalence: 'file.Name' (Internal Dot) leading to Remote Code Execution and/or Information disclosure and/or malicious content added to uploaded files via write enabled Default Servlet in Apache Tomcat. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.2, from 10.1.0-M1 through…

more

10.1.34, from 9.0.0.M1 through 9.0.98. 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. If all of the following were true, a malicious user was able to view security sensitive files and/or inject content into those files: - writes enabled for the default servlet (disabled by default) - support for partial PUT (enabled by default) - a target URL for security sensitive uploads that was a sub-directory of a target URL for public uploads - attacker knowledge of the names of security sensitive files being uploaded - the security sensitive files also being uploaded via partial PUT If all of the following were true, a malicious user was able to perform remote code execution: - writes enabled for the default servlet (disabled by default) - support for partial PUT (enabled by default) - application was using Tomcat's file based session persistence with the default storage location - application included a library that may be leveraged in a deserialization attack Users are recommended to upgrade to version 11.0.3, 10.1.35 or 9.0.99, which fixes the issue.

CWE(s)
KEV Date Added
01 April 2025

Related Threats

MITRE ATT&CK Enterprise Techniques

T1034 Path Interception Persistence
**This technique has been deprecated.
T1190 Exploit Public-Facing Application Initial Access
Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network.
T1203 Exploitation for Client Execution Execution
Adversaries may exploit software vulnerabilities in client applications to execute code.
T1574.008 Path Interception by Search Order Hijacking Stealth
Adversaries may execute their own malicious payloads by hijacking the search order used to load other programs.
T1005 Data from Local System Collection
Adversaries may search local system sources, such as file systems, configuration files, local databases, virtual machine files, or process memory, to find files of interest and sensitive data prior to Exfiltration.
T1036 Masquerading Stealth
Adversaries may attempt to manipulate features of their artifacts to make them appear legitimate or benign to users and/or security tools.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2023-46604Same product: Debian Debian Linuxboth on KEV
CVE-2023-28709Same product: Apache Tomcat
CVE-2024-50379Same product: Apache Tomcat
CVE-2024-56337Same product: Apache Tomcat
CVE-2024-54677Same product: Apache Tomcat
CVE-2017-9805Same product class: NAS / storage applianceboth on KEV
CVE-2021-22600Same product: Debian Debian Linuxboth on KEV
CVE-2024-1086Same product: Debian Debian Linuxboth on KEV
CVE-2021-39144Same product: Debian Debian Linuxboth on KEV
CVE-2024-38475Same product class: NAS / storage applianceboth on KEV

Affected Assets

apache
tomcat
10.1.0, 11.0.0 · ≤ 9.0.99 · 10.1.1 — 10.1.35 · 11.0.1 — 11.0.3
debian
debian linux
11.0
netapp
bootstrap os
all versions

Mitigating Controls

Mitigating Controls (NIST 800-53 r5) AI

Developer testing and evaluation can uncover deserialization flaws before deployment.

Input validation directly stops deserialization of untrusted data by ensuring inputs are valid before processing.

Access enforcement applies authorization checks to the resolved resource, blocking access outside the intended sphere.

Information flow enforcement can constrain flows that result from an incorrectly resolved name or reference.

Engineering principles such as safe deserialization and input sanitization structurally prevent the weakness from being introduced.

Integrity verification tools can detect malformed or tampered serialized data after the fact.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly require input validation to prevent path-equivalence flaws.

PR.AA-05 partial match
prevents

Enforced authorization boundaries limit damage from an incorrectly resolved reference.

PR.IR-01 partial match
prevents

Logical segmentation and access controls reduce the chance an out-of-sphere resolution succeeds.

PR.PS-01 partial match
prevents

Hardened configuration baselines can constrain allowable name-to-resource mappings.

PR.PS-02 none match
prevents

PR.PS-02 addresses only post-deployment updates/patching and cannot prevent introduction of unsafe deserialization code, yet it can remediate some instances when the flaw exists in outdated libraries or components.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

finds

Security testing can discover path-equivalence flaws but does not itself prevent them in production.

degrades

Network segmentation and routing policies reduce the chance that a mis-resolved name leads to an unintended external resource.

degrades

Segregated networks limit the blast radius when a name or reference resolves outside the intended control sphere.

prevents

Secure SDLC practices include design reviews that can catch incorrect name or reference handling before deployment.

prevents

Application security requirements can mandate path validation rules that block internal-dot traversal.

prevents

Secure architecture principles include canonicalization and input sanitization to prevent path equivalence attacks.

References