Independent perspective. Actionable security.Know what matters · Reduce exposure

Vulnerability Assurance / Intelligence

Apache Tomcat Path Equivalence Vulnerability (CVE-2025-24813)

Historical catalog analysis: CISA added this entry on April 01, 2025. The entry reflects catalog information retrieved on August 31, 2026, not a snapshot archived on the inclusion date. Check current vendor guidance before acting.

What the vulnerability is

CVE-2025-24813 is a path equivalence vulnerability identified in Apache Tomcat. The flaw allows a remote attacker to utilize a partial PUT request to achieve several high-impact outcomes, including remote code execution (RCE), unauthorized information disclosure, or the injection of malicious content. This vulnerability is categorized under CWE-44 and CWE-502.

Exposure and applicability

This vulnerability affects Apache Tomcat instances. Because Tomcat is a widely deployed open-source component used across various third-party products and libraries, exposure may exist not only in standalone installations but also within bundled software stacks provided by other vendors.

Infrastructure owners should identify all active Tomcat deployments and consult specific product vendors to determine if their proprietary implementations are affected by this underlying component flaw. The applicability of the vulnerability depends on whether the environment allows the specific request types (partial PUT) required to trigger the path equivalence issue.

Remediation priorities

Based on our analysis, remediation should be prioritized for internet-facing servers and those handling sensitive data, given the remote nature of the exploit. We recommend the following priority sequence:

  1. Vendor Mitigation Application: The primary corrective action is to apply mitigations according to official vendor instructions. For organizations utilizing cloud services, adherence to BOD 22-01 guidance is recommended where applicable.
  2. Decommissioning: In scenarios where vendor mitigations are unavailable or cannot be applied, the source suggests discontinuing use of the affected product version.

How to validate remediation

Verification must go beyond simple version checks. A version string may indicate a patch was applied, but it does not prove that the configuration is secure or that the vulnerability is mitigated in a complex environment.

To verify that exposure has been reduced, defenders should:
* Confirm Mitigation Deployment: Cross-reference installed versions and configurations against the specific requirements detailed in the vendor’s remediation instructions.
* Configuration Audit: Verify that the server configuration restricts or handles PUT requests in accordance with the recommended security posture to prevent the initial entry path.
* Functional Testing: Use authorized testing environments to ensure that the mitigation does not break application functionality while successfully blocking the exploit vector described by the vendor.

Limits and open questions

There are several unknowns regarding this vulnerability. It is currently unknown if this flaw has been utilized in known ransomware campaigns. Additionally, because Tomcat is embedded in many third-party tools, there may be a lag between the availability of the Apache patch and the release of updates from downstream vendors.

Residual risk remains if compensating controls are used instead of a full patch, as these may not address all possible path equivalence permutations. Defenders should remain aware that while mitigations reduce likelihood, they do not provide an absolute guarantee against all forms of exploitation.

Source and editorial note

CVE-2025-24813: Apache Tomcat Path Equivalence Vulnerability · Source date: April 01, 2025 · Retrieved August 31, 2026.

Material facts are tied to the cited primary source. Recommendations are independent defensive analysis unless attributed to the source. Confirm consequential decisions against current authoritative guidance.

Archive date: April 04, 2025. The displayed post date is assigned three days after the source date to organize this retrospective archive; it does not mean this site published the analysis then. First published by this site: October 19, 2026 at 00:31 UTC.

Request a Vulnerability Assessment

Turn security intelligence into action.

Discuss your exposure, priorities, and the evidence needed to validate the outcome.

Request a security assessment ↗

Turn security intelligence into action.

Understand exposure, prioritize the response, and define evidence for the outcome.

Request a Security Assessment