CVE-2025-24813: Critical RCE in Apache Tomcat – Full PoC, Impact, and Mitigation

✍️ By [Rajamohan Reddy] | April 2025

🧪 Application Security | Threat Modeling | API Security | DevSecOps | Container Security | Secure SDLC | SAST | DAST | CEH | ECDE | Red Team | AppSec | Exploit Dev | #POC #Tomcat #CVE2025_24813

Apache Tomcat—one of the most widely used Java-based application servers—is once again in the spotlight due to a critical vulnerability (CVE-2025-24813) that allows attackers to upload malicious serialized Java objects, leading to Remote Code Execution (RCE) or data exfiltration under certain misconfigurations. The bug hits when Tomcat is misconfigured to allow HTTP methods and session persistence is enabled — opening the door to silent exploitation

🔍 Summary:

A critical RCE (Remote Code Execution) vulnerability exists in Apache Tomcat, tracked as CVE-2025-24813, affecting systems that:

• Allow HTTP PUT requests.

• Have session persistence enabled.

• Include commons-collections-3.2.1.jar in their classpath.

This results in exploitable Java deserialization, confirmed through DNS callbacks via tools like ysoserial and Burp Collaborator.

⚠️ Disclaimer: This content is intended strictly for educational and research purposes only. All demonstrations and examples should be run in a controlled, isolated lab environment that you own or are authorized to use. Do not attempt to exploit systems you do not have explicit permission to test. Unauthorized access or exploitation of systems is illegal and unethical. Stay safe, stay legal. 🛡️🔍

Let’s walk through this step-by-step — from vulnerable setup to detection, exploitation, and mitigation. 🧪🛡

📌 Affected Apache Tomcat Versions:

⚙️ Step-by-Step PoC Reproduction (Red Team Lab Setup)

📁 Step 1: Install Vulnerable Apache Tomcat

You can download any vulnerable version from the Tomcat archive – for example:

⚙️ Step 2: Enable Dangerous Configuration (PUT + Sessions)

🔧 File 1: conf/web.xml

💡 Path: 🧠 This change allows uploading files using PUT, which is typically disabled.

Before (default):

After (for PUT to work):

🔧 File 2: conf/context.xml

💡 Path: 🧠 This saves session data to a file, which gets deserialized on server restart.

Before (default):

❗️This has no session persistence enabled — nothing gets serialized or reloaded on startup.

After (persistence enabled):

📦 Step 3: Add Exploitable Java Library

Copy the vulnerable version of Apache Commons Collections:

This library is necessary to exploit insecure deserialization (via ).

🚀 Step-by-Step Exploitation

🔥 Step 4: Generate DNS Trigger Payload with ysoserial

👉 Replace with your Burp Collaborator or OASTify subdomain to detect DNS callbacks.

🐍 Step 5: Upload Malicious Serialized Object

💡 This simulates session persistence and saves the payload as raja.session.

If you're testing file uploads or verifying whether a partial PUT operation is working, you can confirm by checking for uploaded session files in a specific directory on your Linux server.

Typically, files are saved under the following path — especially if the Tomcat web application has write permissions:

For example:

You're looking for files like:

Or any custom-named file generated during your PUT request or test upload.

🔁 Step 6: Restart the Tomcat Server

⏱ Upon restart, Tomcat reads and deserializes the uploaded raja.session.

🌐 Step 7: Observe Callback

Check your Burp Collaborator or OASTify logs. If you see a DNS hit – boom 💥, the server deserialized your payload.

✔️ Vulnerability confirmed.

🧩 Step 8 Alternative for 6 to Reproduce Without Restart (No Downtime Method): Trigger Deserialization via JSESSIONID

If Tomcat is actively using session persistence and you upload a file like , you can manually invoke deserialization by sending a request with a forged cookie:

Or in Python:

✅ How This Works:

• The file you uploaded is a serialized Java object in Tomcat’s session directory.

• When you send a request with , Tomcat tries to load that session file as if it belongs to the client.

• If session persistence is enabled, Tomcat deserializes on-demand, no restart required — effectively triggering the exploit in real time.

💥 Bonus Tip:

If you want to further simulate or test, check this path for uploaded sessions (on Linux):

Look for or your custom file to confirm it landed.

🔗 Section 1: Potential Attack Chain

This outlines the steps an attacker might follow, like a playbook:

1. Upload a malicious serialized Java payload (e.g., via partial PUT)

2. Trigger deserialization through session restore

3. Achieve Remote Code Execution (RCE)

4. Establish persistence or open a reverse shell

5. Pivot within the internal network (move laterally)

💡 This focuses on the method — the how of the attack.

💥 Section 2: What’s the Impact?

This explains the results or damage of the attack:

• Remote Code Execution (RCE): Attacker runs code with server privileges

• Lateral Movement: Uses RCE to spread across systems

• Data Exfiltration: Steals sensitive data

• Persistence: Attack survives reboots (e.g., malicious file re-uploaded)

💡 This focuses on the effect — the so what of the attack.

🔐 How to Fix It (ASAP!): Critical Fix Instructions

✅ 1. Upgrade Immediately

Patch to:

📥 Tomcat Downloads

🔒 2. Harden Configuration

✅Disable PUT and Partial PUTs in web.xml

✅ Disable Session Persistence in context.xml

This is the cleanest way to tell Tomcat:

"Don’t persist sessions to disk — only keep them in memory."

Or Even Safer Option (Completely Remove the Manager) is completely remove the tag.

🧼 3. Clean up Dangerous Libraries

• Remove

• Audit all files in

• Avoid using Java serialization in new projects

👁 4. Monitor & Detect

• Monitor logs: Watch for suspicious requests or file uploads

• Use WAF rules: Block serialized objects in requests

• Enable IDS/IPS: For catching deserialization indicators (e.g., known object signatures)

🛡️ 5. Best Practices

• Set file permissions to restrict access to conf & lib

• Block and methods on production servers

• Enable input validation and object filtering

• Use WAF rules to block .ser .session .class and .jar , etc uploads

🧠 Final Thoughts

CVE-2025-24813 reminds us that even old-school tech like Java serialization still hides serious risk when misconfigurations and legacy components meet.

🔁 Whether you're Red Team or Blue Team, understanding these chains is crucial.

✅ Patch. ✅ Harden configs. ✅ Monitor everything.

📌Reminder: Hack responsibly. Always test in isolated environments you control.

🧵 Share Your Thoughts

Have you seen this exploited in the wild? Planning to check your infra? I’d love to hear your take or help you walk through remediation.

#CyberSecurity #ApacheTomcat #CVE2025_24813 #AppSec #JavaSecurity #Deserialization #RedTeam #BlueTeam #DevSecOps #PoC