Yes. CISA added CVE-2025-24813 to its Known Exploited Vulnerabilities catalogue on 1 April 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apache Tomcat contains a path equivalence vulnerability that allows a remote attacker to execute code, disclose information, or inject malicious content via a partial PUT request.
What “being exploited in the wild” means for this Tomcat CVE
CISA’s KEV inclusion is the practical signal that this is not just a theoretical Tomcat flaw. For defenders, the question is no longer whether the bug can be abused, but whether any Tomcat instance is exposed to the vulnerable path-equivalence behaviour and reachable by a remote attacker using a partial PUT request.
That matters because path-equivalence issues often turn a seemingly narrow request-handling flaw into a broader server compromise path. In Zero-Day and Exploited Vulnerabilities Guide, the operational priority is the same one that applies here, confirm exposure quickly, treat KEV status as an escalation trigger, and assume exploitation may already have begun if the service was internet-facing.
Apache Tomcat is the primary subject here, but the security consequence is classic web-server exploitation: code execution, information disclosure, or malicious content injection can follow from successful request manipulation. When a CVE reaches KEV, the defensive posture changes from routine backlog management to immediate verification, containment, and compromise assessment.
What to verify before you assume you are safe
Start by confirming whether any Tomcat deployment in your environment is reachable and whether it accepts the request patterns that make this issue material. If Tomcat is embedded in an application stack, verify the actual runtime exposure, not just the package inventory entry, because internet-facing reverse proxies, application servers, and staging systems can be overlooked even when the software estate looks current on paper.
Use CISA Known Exploited Vulnerabilities Catalog as the authoritative exploitation reference, and cross-check it with the vendor advisory for the exact affected release and remediation guidance. For NIST Cybersecurity Framework 2.0 terms, this is a detect-and-protect problem first: asset visibility, exposure confirmation, and fast remediation matter more than debating whether the vulnerability exists in the abstract.
Do not stop at “we patched eventually.” If the server was exposed during the KEV window, check whether logs show unusual PUT activity, unexpected content placement, malformed paths, or new files and behaviours that do not match normal application traffic.
What to do when patching has to wait
If immediate patching is not possible, reduce exposure in the request path that the flaw depends on. That usually means tightening access to the Tomcat endpoint, blocking or constraining partial PUT handling where feasible, and limiting who can reach the service at network and application layers until the fix is applied.
For the control plane, a vulnerability-management workflow should treat a KEV-listed Tomcat issue as an emergency item, not a standard SLA ticket. Vulnerability Management Guide is the right operational frame here, prioritise by exploitability and exposure, track exceptions explicitly, and require post-remediation verification rather than assuming a package change is enough.
If Tomcat fronts a business-critical application, the safest interim decision is often to isolate the service, reduce reachable surface area, and increase monitoring rather than leaving an exposed instance online while waiting for a maintenance window. The relevant trade-off is availability versus blast radius, and KEV status usually means the blast radius argument wins.
What compromise checks matter after exposure
Where Tomcat may have been reachable, look for evidence that the vulnerability was used to place or alter files, inject content, or gain execution on the host. That includes unexpected webshell-like artefacts, new scheduled tasks or startup changes, suspicious child processes from the application runtime, and signs that the application directory or adjacent paths were modified outside normal deployment activity.
Because this flaw can lead to code execution, compromise review should extend beyond the immediate application. Validate whether the host was used to pivot into internal services, whether local secrets were accessible from the process context, and whether the application account had more privilege than it needed for normal operation. If the server also handled credentials or session material, rotate anything the host could have exposed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed Tomcat flaws require rapid prioritisation and verification of exposure. |
| Recommendation — Prioritise, remediate, and verify KEV-listed vulnerabilities first. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | You must know where Tomcat is deployed before you can assess exposure or exploitation. |
| DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | Exploitation checks depend on observing suspicious requests and post-exploit behaviour. | |
| Recommendation — Inventory every Tomcat instance and confirm its exposure path. Monitor for anomalous Tomcat request patterns and post-exploit artefacts. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | A KEV-listed vulnerability requires expedited remediation and verification. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Log review is needed to detect exploitation and follow-on activity. | |
| Recommendation — Accelerate patching and confirm remediation for the Tomcat flaw. Review Tomcat and host logs for signs of exploitation and persistence. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | Attack confirmation depends on trustworthy logs and error visibility. |
| Recommendation — Preserve and inspect application logs for suspicious request handling. | ||
Practitioner Guidance
What to prioritise: If the instance was internet-facing during the exploitation window, prioritise triage, containment, and compromise assessment before routine patch scheduling. A KEV entry is a signal to assume active attacker interest, not a reason to wait for additional proof.
What to verify: Confirm the exact Tomcat deployment path, the real network exposure, and whether request logs show suspicious partial PUT or path-manipulation activity. If you cannot prove the service was unreachable, treat it as potentially exposed.
Decision rule: If patching is delayed, reduce reachability and monitor aggressively; if there is any sign of file placement, content injection, or execution from the Tomcat process, escalate to incident response and rotate any secrets that instance could access.
Practitioner takeaway: For KEV-listed server flaws, the right question is not only “is it exploited in the wild?”, but “has my exposed instance already been used as the initial foothold?”
Related resources from NHI Mgmt Group
- CVE-2025-24813 (Apache Tomcat Path Equivalence)
- How should security teams reduce exposure to CVE-2025-24813 in Apache Tomcat before patching is complete?
- Is CVE-2025-2747 (Kentico Xperience CMS Authentication Bypass Using an Alternate Path or Channel) being exploited in the wild?
- Is CVE-2025-33053 (Microsoft Windows External Control of File Name or Path) being exploited in the wild?