CVE-2026-55574 in vLLM
Summary
by MITRE • 07/06/2026
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Prior to 0.24.0, the structured_outputs.regex API parameter passes a user-supplied regular expression string directly to the grammar compiler backends with no compilation timeout; in the xgrammar backend the string reaches the regex compiler with no guard, and in the outlines backend the validation step blocks structural issues such as lookarounds and backreferences but performs no complexity analysis, so a pattern with nested quantifiers passes all checks and causes exponential state-space expansion, allowing a single request containing an adversarial regex to hang an inference worker indefinitely and deny service. This issue is fixed in version 0.24.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/06/2026
The vLLM inference engine presents a critical vulnerability in its structured_outputs.regex API parameter that enables remote denial of service attacks through carefully crafted regular expressions. This flaw affects versions prior to 0.24.0 and stems from inadequate input validation and timeout mechanisms within the grammar compiler backends. The vulnerability manifests when user-supplied regex patterns are passed directly to backend compilers without proper sanitization or complexity analysis, creating a pathway for malicious actors to exploit the system's computational resources.
The technical implementation of this vulnerability operates through two distinct backend pathways that compound the risk. In the xgrammar backend, user regex strings bypass any compilation guards entirely, allowing unrestricted access to the underlying regex compiler. Meanwhile, the outlines backend implements validation checks that appear sufficient but fail to address complexity issues such as nested quantifiers. These validation mechanisms prevent obvious structural problems like lookarounds and backreferences but permit patterns with exponential state-space expansion to proceed unchecked, creating a false sense of security while enabling devastating computational attacks.
The operational impact of this vulnerability extends beyond simple resource exhaustion to constitute a complete denial of service condition that can persist indefinitely. An adversarial regex pattern containing nested quantifiers can trigger exponential state-space expansion within the grammar compiler, causing a single malicious request to consume all available computational resources for an inference worker. This behavior effectively renders the affected worker unusable for legitimate requests while maintaining no timeout or resource limit mechanisms to prevent indefinite hanging. The vulnerability creates a persistent threat that can be exploited repeatedly without requiring authentication or advanced privileges.
The mitigation strategy implemented in vLLM version 0.24.0 addresses this issue through comprehensive timeout mechanisms and enhanced input validation across both backend compilers. This update introduces proper compilation timeouts that prevent any single regex pattern from consuming excessive computational resources, while also implementing more rigorous complexity analysis to identify potentially dangerous patterns before they can trigger exponential expansion. The fix aligns with established security practices for preventing regex denial of service attacks and demonstrates the importance of implementing defensive programming measures in high-throughput systems where user input directly influences computational resource allocation.
This vulnerability type corresponds to CWE-400, which specifically addresses "Uncontrolled Resource Consumption" and falls under the broader category of resource exhaustion attacks. The implementation pattern follows ATT&CK technique T1499.004 for "Resource Hijacking" by consuming excessive computational resources through malformed input processing. Organizations utilizing vLLM should prioritize immediate upgrade to version 0.24.0 or later to address this vulnerability, as the attack vector requires no special privileges and can be executed through standard API requests, making it particularly dangerous in production environments where service availability is critical for business operations.