CVE-2026-73555 in vLLM
Summary
by MITRE • 08/13/2026
vLLM is an inference and serving engine for large language models. Prior to 0.26.0, the validation_exception_handler in vllm/entrypoints/openai/server_utils.py converts FastAPI RequestValidationError objects with str(exc), and sanitize_message in vllm/entrypoints/utils.py does not remove traceback-style file paths, allowing unauthenticated malformed JSON requests to /v1/chat/completions, /v1/completions, /tokenize, and /detokenize to disclose the OS username, home and virtual-environment paths, Python version, internal package structure, line numbers, and endpoint handler names. This issue is fixed in version 0.26.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/13/2026
The vulnerability described affects vLLM, a popular inference and serving engine for large language models that has gained significant traction in the AI community due to its performance and ease of deployment. This security flaw represents a critical information disclosure vulnerability that impacts the confidentiality of system information through improperly handled error responses. The issue manifests in the way the system processes malformed JSON requests to several core endpoints including /v1/chat/completions, /v1/completions, /tokenize, and /detokenize, where the validation_exception_handler component fails to properly sanitize error messages before returning them to clients.
The technical flaw resides in the validation_exception_handler function within vllm/entrypoints/openai/server_utils.py which converts FastAPI RequestValidationError objects using str(exc) without adequate sanitization. This approach directly exposes internal system details including the operating system username, home directory paths, virtual environment locations, Python version information, internal package structure layouts, specific line numbers where errors occur, and endpoint handler names. The sanitize_message function in vllm/entrypoints/utils.py fails to remove traceback-style file paths that contain sensitive operational information, creating a pathway for attackers to gather detailed system reconnaissance data through seemingly benign error responses.
The operational impact of this vulnerability is significant as it provides unauthenticated attackers with comprehensive system fingerprinting capabilities without requiring any prior authentication or privilege escalation. This information disclosure can be leveraged by threat actors to perform targeted attacks against the specific environment, potentially identifying weak points in the deployment architecture, understanding the software stack configuration, and planning more sophisticated exploitation techniques. The vulnerability affects the core functionality of the API endpoints and exposes sensitive operational details that could aid in supply chain attacks or targeted intrusions.
This issue aligns with CWE-209, "Information Exposure Through an Error Message," which specifically addresses the problem of revealing internal system information through error handling mechanisms. It also relates to ATT&CK technique T1592, "Get Details of Network Service," as attackers can gather comprehensive information about the hosting environment and service configuration. The vulnerability demonstrates poor input validation practices where error responses are not adequately sanitized before being exposed to external parties, creating an information leakage channel that violates security best practices for secure coding.
The fix implemented in version 0.26.0 addresses this by properly sanitizing error messages to remove or obscure sensitive system information while still providing meaningful error feedback to legitimate users. Organizations using vLLM should immediately update to version 0.26.0 or later to mitigate this exposure and implement additional monitoring for malformed requests that may indicate attempted exploitation of this vulnerability. Security teams should also consider implementing rate limiting and request validation at the network level to further reduce the attack surface while the application-level fix is being deployed.