Detecting and Mitigating Apache Tomcat CVE-2025-24813
Executive summary
On March 10, 2025, a path equivalence vulnerability in Apache Tomcat (assigned CVE-2025-24813) was publicly disclosed, along with a patch for it.
While the vulnerability could allow for RCE, it is considered by Apache to be a moderate severity vulnerability, as it has specific non-default prerequisites to be exploitable.
Shortly after the vulnerability was published, Akamai began seeing initial exploit attempts probing potential servers for this vulnerability.
In this blog post, Akamai researchers provide in-depth details about the vulnerability, exploitation techniques, and detection strategies.
An Akamai Adaptive Security Engine Rapid Rule is automatically providing protection for Akamai App & API Protector customers.
We also provide an Akamai Guardicore Segmentation Insight query for detection.
- Akamai Hunt customers who were affected have already received detailed mapping of vulnerable assets.
What is CVE-2025-24813?
On March 10, 2025, a path equivalence vulnerability within Apache Tomcat, a popular open source web server and Java servlet container commonly used to host Java-based applications (CVE-2025-24813), was announced alongside the patch for it. The flaw specifically affects how the server processes file paths internally. Mere days after release of a public proof of concept, attackers were trying to exploit it in the wild, following a troubling trend we’ve seen lately: a continuously shrinking time to exploitation.
Apache labeled CVE-2025-24813 as moderate severity due to exploitation requirements. A vulnerable server has to meet a specific set of prerequisites, making this issue less likely to be exploitable. However, regardless of these prerequisites, as the vulnerability could lead to unauthenticated remote code execution (RCE) if exploited, it is important to patch it immediately.
The vulnerability was fixed in Apache Tomcat versions 11.0.3, 10.1.35, and 9.0.99, but servers running versions 11.0.0-M1 to 11.0.2, 10.1.0-M1 to 10.1.34, and 9.0.0-M1 to 9.0.98 might still be vulnerable.
What is CVE-2025-24813?
When an Apache Tomcat’s default servlet is configured to enable write functionality, which is disabled by default, an attacker can have a significant impact using CVE-2025-24813. When combined with the default behavior of allowing partial PUT requests, an attacker can upload a specially crafted, serialized session file for example to a writable directory. Once this file has been uploaded, a subsequent HTTP request forces the Tomcat to deserialize its contents, which triggers the execution of the embedded payload.
Exploitation can result in RCE, severe information leakage, or malicious content injection that can also corrupt critical server configuration files. The affected Apache Tomcat versions include 11.0.0‑M1 through 11.0.2, 10.1.0‑M1 through 10.1.34, and 9.0.0‑M1 through 9.0.98.
Exploiting CVE-2025-24813
The end result of exploitation is quite severe but achieving RCE through this vulnerability requires a robust set of prerequisites:
The default servlet must have write capability explicitly enabled
Partial PUT requests must be permitted
The web application must use file-based session persistence with default storage location (providing a writable target directory for the malicious serialized payload)
A deserialization-vulnerable library must be present or in use by the application (allowing the payload execution to take place via a deserialization attack)
Additionally, an attacker must have a knowledge of the internal file naming conventions used by the application and the directory structure of the target’s file system
While most prerequisites may be in place, the most critical one — the default servlet write capability — is disabled by default.
Observed attack traffic
The Akamai Security Intelligence Group (SIG) identified attack traffic very shortly after the vulnerability was disclosed. Most of the observed attack payloads are vulnerability probes designed to help attackers determine whether the target server is vulnerable. A common attack variant specifically targets .session file paths, which follow a randomized naming scheme — a six-character base appended with the .session file extension (Figure 1).
Fig. 1: Examples of .session attack variant
The most popular payload included a .session file in as the request body, which consisted of malicious Java serialized objects. In most cases, the malicious object will use the java.net.URL object to “call home” once this uploaded session file is deserialized by Apache Tomcat (Figure 2).
Fig. 2: Attempted .session payload in request body
Detecting vulnerable applications
Identifying every vulnerable instance of Apache Tomcat across a network can be challenging. Security teams must assess a wide range of assets, as Apache Tomcat is integrated in numerous places, including applications in which libraries are being used that defenders are unaware of.
Similar to the recent Apache Camel vulnerability, this library may be present as an indirect dependency, meaning it is not explicitly included in the source code but is instead introduced through another software package. This adds a layer of complexity for detection and, of course, mitigation.
Apache Tomcat can be installed on its own on both Windows and Linux, or be a part of Kava applications. It can be detected by recursively scanning directories for Java archive (JAR) files called tomcat-api.jar. Once a Tomcat-related JAR file is located, its manifest file can be examined to determine the version in use.
With the extracted version, security teams can cross-reference it against Apache’s security advisory to assess potential vulnerabilities. The following versions are affected:
- Apache Tomcat 11.0.0-M1 to 11.0.2
- Apache Tomcat 10.1.0-M1 to 10.1.34
- Apache Tomcat 9.0.0.-M1 to 9.0.98
Automating detection
For Akamai Guardicore Segmentation customers, we have built an Insight query that can identify vulnerable assets. The query will return all available paths and hashes for tomcat-api.jar. The returned JAR can be either checked in VirusTotal via hash or through the manifest file inside the JAR to get to the correct version.
Windows — Apache Tomcat within applications
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE LOWER(proc.name) LIKE "%tomcat%"
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '..\%\%\tomcat-api.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '..\%\tomcat-api.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '%\%\tomcat-api.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT DISTINCT lib_path, cwd, jar_path, sha256
FROM RELEVANT_JAR_PATHS
Linux — Apache Tomcat within applications
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE LOWER(proc.name) LIKE "%tomcat%"
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '../%/%/tomcat-api.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '../%/tomcat-api.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '%/%/tomcat-api.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT DISTINCT lib_path, cwd, jar_path, sha256
FROM RELEVANT_JAR_PATHS
Windows — Apache Tomcat installed
SELECT name, version
FROM programs
WHERE name LIKE '%tomcat%'
AND ((version >= '11.0.0' AND version <= '11.0.2') OR (version >= '10.1.0' AND version <= '10.1.34') OR (version >= '9.0.0' AND version <= '9.0.98'))
Linux — Apache Tomcat installed
SELECT name, version
FROM deb_packages
WHERE name LIKE '%tomcat%'
AND ((version >= '11.0.0' AND version <= '11.0.2') OR (version >= '10.1.0' AND version <= '10.1.34') OR (version >= '9.0.0' AND version <= '9.0.98'))
UNION
SELECT name, version
FROM rpm_packages
WHERE name LIKE '%tomcat%'
AND ((version >= '11.0.0' AND version <= '11.0.2') OR (version >= '10.1.0' AND version <= '10.1.34') OR (version >= '9.0.0' AND version <= '9.0.98'))
Mitigating with Akamai App & API Protector
Many exploit attempts are mitigated by existing Adaptive Security Engine rules, including those that detect Java deserialization attempts (Figure 3).
3000072 - Deserialization Attack Detected
Fig. 3: Adaptive Security Engine rule 3000072 detecting CVE-2025-24813 exploit attempt
On March 19, 2025, Akamai’s Threat Research Team also deployed Adaptive Security Engine Rapid Rule for App & API Protector customers to provide full coverage (Figure 4).
3000957 — Apache Tomcat Remote Code Execution Attack Detected (CVE-2025-24813)
Fig. 4: Adaptive Security Engine Rapid Rule provides full coverage
Version 1 of the Rapid Rule has default action set to Alert. To block the attack attempts, customers are advised to set the rule action to Deny after reviewing the triggers to eliminate any false positives.
Summary
The Akamai SIG will continue to monitor, report on, and create mitigations for threats such as these for both our customers and the security community at large. To keep up with more breaking news from the Akamai Security Intelligence Group, check out our research home page and follow us on social media.