CVE-2025-24813: Serious vulnerability in Apache Tomcat-Executing the remote code (RCE). Update the patch immediately

Introduction
A critical vulnerability, identified as CVE-2025-24813, has been discovered in Apache Tomcat. This vulnerability could allow an attacker to execute remote code (Remote Code Execution – RCE), disclose sensitive information, or corrupt data. The Apache Software Foundation has issued an urgent security advisory, urging users of affected versions to update immediately.
The vulnerability stems from Tomcat's incorrect handling of file paths containing internal dots, leading to the potential for remote code execution, information disclosure, or data corruption. An attacker could upload a malicious “Java session file” through a PUT request, which could then be triggered to execute code on the server.
Affected Versions
Tomcat versions from 9.0.0.M1 to 9.0.98
Tomcat versions from 10.1.0-M1 to 10.1.34
Tomcat versions from 11.0.0-M1 to 11.0.2
Vulnerability Description
Vulnerability ID: CVE-2025-2483
CVSS Score: 8.6/10, indicating a high severity level.
Attack Mechanism: This vulnerability could allow an attacker to execute remote code (Remote Code Execution – RCE), disclose sensitive information, or corrupt data.
Consequences:
Information Leakage and Data Corruption: An attacker could view sensitive files or insert malicious content into them.
Remote Code Execution (RCE)
Workflow
This vulnerability exploits Tomcat's default session handling, and attackers have carried out the exploit through two basic steps:
The attacker uploads a
“Serialized Java session“through a PUT request.The attacker uses the malicious session ID to send requests to the victim's machine.
Details of the Implementation
Step 1: Upload Malicious Session
Initially, attackers will check if Tomcat stores sessions.
- The attacker will access
context.xmland look forPersistentManager.
- The attacker will access

If so, the session can be saved and restored after Tomcat restarts
The next step is for the attacker to create a malicious serialized payload
- Use ysoserial to create a malicious session:

Use reverse shell:

The next step attackers will take is to upload a malicious session. There are three main ways to upload a session into Tomcat:
File write attack through file upload vulnerability: If the application has a file upload feature, the attacker can upload
session.serto the/work/Catalina/localhost/.PUT Request attack (if misconfigured):

Exploiting CVE-2025-24813 or similar vulnerabilities: If Tomcat mishandles file paths, an attacker can write a session file to the directory used for session recovery.
Step 2: Activate Malicious Session
When the session file is uploaded, the attacker will trigger the deserialization process by sending a simple GET request with the jsessionid pointing to the malicious session.

Then, when Tomcat sees this session ID, it will retrieve the stored file and execute the embedded Java code, granting the attacker full remote access.
Mitigation Measures
Update Apache Tomcat to the latest version: This vulnerability has been fixed in Tomcat versions 11.0.3, 10.1.35, and 9.0.98. Upgrading to these versions will help eliminate the risk of being attacked through this vulnerability.
Review and reconfigure security settings:
Disable unnecessary HTTP methods: If your application does not use the
PUTmethod, disable it to reduce the attack surface.Restrict access to sensitive directories: Ensure that only necessary users or services have write access to important directories.
Monitor and regularly check the system: Keep an eye on log files and system activities to detect early signs of unusual behavior or attack attempts.
Implement additional security measures:
Use a web application firewall (WAF): A WAF can help block malicious requests before they reach your server.
Conduct regular security assessments: Regular security evaluations will help identify and promptly address new vulnerabilities.
Conclusion
"Uploading a Malicious Serialized Session" is a common attack technique if a Tomcat application is not securely configured. Attackers can exploit Tomcat's session storage and deserialization to execute remote code. The best way to prevent this is to disable session serialization, filter inputs, and use more secure session storage mechanisms.






