# 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:

1. The attacker uploads a `“Serialized Java session“` through a PUT request.
    
2. 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.xml` and look for `PersistentManager`.
        
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742087538439/d0ed6106-dacf-4fe8-96a0-a2a6077bc2f1.png align="center")
    
    * 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:
            
        
        ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742088560651/0206829d-babf-4a05-bf64-9f8fb32f45a2.png align="center")
        
    * Use reverse shell:
        
        ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742088720826/6cfa9ba3-a3a5-4cd5-8359-12abdedbd64d.png align="center")
        
* 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.ser` to the `/work/Catalina/`[`localhost/`](http://localhost/).
        
    * PUT Request attack (if misconfigured):
        
        ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742089875574/813d4f6f-6c0b-484b-be94-02b5618d6910.png align="center")
        
    * **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.
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742093520638/5c27dcf8-cf3d-4a0d-8aaf-115a264c3c82.png align="center")
    
* 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**

1. **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.
    
2. **Review and reconfigure security settings**:
    
    * **Disable unnecessary HTTP methods**: If your application does not use the `PUT` method, 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.
        
3. **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.
    
4. **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**.

## **References**

1. [CVE-2025-24813 Flaw in Apache Tomcat Exposes Servers to RCE, Data Leaks: Update Immediately](https://securityonline.info/cve-2025-24813-flaw-in-apache-tomcat-exposes-servers-to-rce-data-leaks-update-immediately/)
    
2. [One PUT Request to Own Tomcat: CVE-2025-24813 RCE is in the Wild - API Security](https://lab.wallarm.com/one-put-request-to-own-tomcat-cve-2025-24813-rce-is-in-the-wild/)