CVE-2025-71379: vLLM ReDoS Vulnerability in Regex Parsing (0.6.3–0.9.0)

Technical summary

The vulnerability class is Regular Expression Denial of Service (ReDoS), cataloged as CWE-1333. Catastrophic backtracking occurs when certain regex patterns, typically those with nested quantifiers or alternations, are fed input that causes exponential exploration of matching possibilities. In vLLM's case, the affected patterns appear in: (1) vllm/lora/utils.py for LoRA configuration parsing, (2) phi4mini tool parser logic, and (3) the OpenAI chat-compatible endpoint input validation. The issue is triggered by supplying input with repetitive or deeply nested structures that violate the intended format but satisfy intermediate regex states, causing the engine to backtrack extensively. This is distinct from injection or memory corruption; rather, it's an algorithmic complexity issue in pattern matching.

Business impact

For organizations running vLLM in production—whether for internal model serving, API endpoints, or multi-tenant scenarios—this vulnerability creates a straightforward denial of service vector. An authenticated user (or someone with access to the affected endpoints) can trigger request-level CPU exhaustion. If LoRA fine-tuning endpoints are exposed or if the chat API is customer-facing, availability can be severely impacted. Multi-tenant deployments are particularly at risk, as one tenant's malicious input could degrade service for others. Incident response overhead, customer SLA breaches, and reputational damage are secondary concerns if the service becomes unavailable.

Affected systems

vLLM versions 0.6.3, 0.6.4, 0.7.x, 0.8.x, and 0.9.0 (pre-release) are in scope. Earlier versions (< 0.6.3) and versions 0.9.0 and later (once patched) are unaffected. The vulnerability affects any deployment using these versions, regardless of hardware or hosting model, provided the affected code paths are reachable—specifically, if LoRA utilities are invoked, if phi4mini tool parsing is enabled, or if the OpenAI-compatible chat endpoint is exposed.

Exploitability

Exploitability is moderate. The attack requires authentication (PR:L per the CVSS vector), meaning unauthenticated external attack is not possible; however, any authenticated user or internal actor with API access can trigger it. Crafting the payload is straightforward—no complex tooling or prior knowledge of the system internals is required beyond understanding how to format nested or repeated strings in the affected input fields. There is no public indication this is being actively exploited in the wild, but the attack surface is large given vLLM's popularity. The CVSS score of 4.3 reflects the authentication requirement and the absence of confidentiality or integrity impact; availability impact is localized and can be mitigated by service restart.

Remediation

Upgrade to vLLM version 0.9.0 or later. The development team has patched the regex patterns to eliminate catastrophic backtracking, likely by refactoring to iterative parsing, using non-backtracking regex constructs, or implementing input validation and length limits before regex application. Organizations unable to upgrade immediately should restrict access to the affected endpoints (LoRA APIs and OpenAI chat endpoint) to trusted internal users only, implement rate limiting on regex-heavy code paths, and monitor CPU usage for anomalies indicative of ReDoS attacks.

Patch guidance

1. Identify which vLLM version(s) are currently deployed in your environment. 2. Plan an upgrade to version 0.9.0 or later during a maintenance window. 3. Test the new version in a staging environment, particularly the OpenAI chat endpoint and any LoRA fine-tuning workflows, to ensure compatibility with your downstream integrations. 4. Review your vLLM configuration for any customizations to the affected regex patterns; if you have forked or modified the codebase, apply the same regex fixes to your custom code. 5. After deployment, monitor error logs and latency metrics for the first week to confirm stability.

Detection guidance

Monitor for signs of ReDoS exploitation: (1) Unexpected spikes in CPU utilization on vLLM processes, especially during API requests; (2) Slowdowns or timeouts in chat endpoint responses without corresponding increases in model inference latency; (3) Requests with unusually long or deeply nested strings in payload fields (e.g., LoRA configuration, tool parser input, or chat messages with many repetitions); (4) Error logs from the regex engine or timeout exceptions in vllm/lora/utils.py or chat handling code. Set alerts on per-request CPU time for these endpoints and consider logging full request payloads in debug mode for suspected ReDoS attempts.

Why prioritize this

Although the CVSS score is moderate (4.3), this vulnerability should be prioritized for patching because: (1) vLLM is widely used in production LLM serving pipelines; (2) the attack requires only valid credentials, which are often distributed across teams; (3) the impact—complete availability loss for an endpoint—is operationally severe; (4) the patch is straightforward and low-risk; (5) exploitation requires no sophisticated tools. Organizations relying on vLLM for customer-facing or mission-critical inference should treat this as high-priority.

Risk score, explained

The CVSS 3.1 score of 4.3 (MEDIUM) is calculated as: Attack Vector=Network (can be triggered remotely), Attack Complexity=Low (no special conditions needed), Privileges Required=Low (authenticated user), User Interaction=None, Scope=Unchanged (impacts only the vLLM service), Confidentiality=None, Integrity=None, Availability=Low (denial of service impact). The 'Low' availability impact reflects that the DoS is service-level and can be recovered by restarting the process, not a permanent or irrecoverable state. The authentication requirement prevents it from scoring higher despite the operational severity.

Frequently asked questions