CVE-2026-73555

Ein Angreifer kann mehrere Schwachstellen in vllm ausnutzen, um Informationen offenzulegen, Daten zu manipulieren, Sicherheitsmaßnahmen zu umgehen oder einen Denial-of-Service-Zustand herbeizuführen.

## Summary When the vLLM API receives a malformed request (e.g., invalid JSON or missing required fields), FastAPI raises a Pydantic `RequestValidationError`. The `validation_exception_handler` in `vllm/entrypoints/openai/server_utils.py` converts this exception to a string via `str(exc)`, which includes the internal file path and line number of the handler function. The existing `sanitize_message()` function in `vllm/entrypoints/utils.py` strips memory addresses (e.g., `0x7f...`) but does not strip `File "...", line X` patterns. The result is a user-facing HTTP response that leaks internal system information. ## Impact An unauthenticated attacker can extract the following with a single malformed request: - **OS username** running the vLLM process (e.g., `ubuntu`) - **Home directory path** (e.g., `/home/ubuntu/`) - **Virtual environment path** (e.g., `vllm-env/`) - **Python version** (e.g., `3.12`) - **Internal package structure and line numbers** (e.g., `vllm/entrypoints/openai/chat_completion/api_router.py`) - **Handler function names per endpoint**, enabling precise version fingerprinting This information aids attackers in constructing targeted exploits: environment paths narrow the attack surface, and handler function names + line numbers enable exact version identification even when the `/version` endpoint is disabled. All POST endpoints that accept JSON bodies are affected, including `/v1/chat/completions`, `/v1/completions`, `/tokenize`, and `/detokenize`. ## Workarounds Deploying vLLM behind a reverse proxy that rewrites error response bodies to strip file paths would mitigate this, though it is fragile. ## Remediation Recommendation Two possible fixes (either suffices): **Option A — Fix `validation_exception_handler`:** Construct the error message from `exc.errors()` (the structured Pydantic error list) rather than `str(exc)`. This avoids the traceback-style string entirely. **Option B — Fix `sanitize_message`:** Add a regex to strip `File "...", line \d+` patterns, similar to how memory addresses are already stripped: ```python import re msg = re.sub(r'File ".*?", line \d+, in \w+', '[internal]', msg) ``` Option A is preferred as it addresses the root cause rather than filtering symptoms. ## Environment Tested - vLLM 0.20.1 (pip install, latest stable as of May 2026) - Python 3.12 - Ubuntu 22.04 - Model: Qwen/Qwen2-0.5B (text-only; bug is model-independent) This was fixed here: https://github.com/vllm-project/vllm/commit/e87521626f

## Summary When the vLLM API receives a malformed request (e.g., invalid JSON or missing required fields), FastAPI raises a Pydantic `RequestValidationError`. The `validation_exception_handler` in `vllm/entrypoints/openai/server_utils.py` converts this exception to a string via `str(exc)`, which includes the internal file path and line number of the handler function. The existing `sanitize_message()` function in `vllm/entrypoints/utils.py` strips memory addresses (e.g., `0x7f...`) but does not strip `File "...", line X` patterns. The result is a user-facing HTTP response that leaks internal system information. ## Impact An unauthenticated attacker can extract the following with a single malformed request: - **OS username** running the vLLM process (e.g., `ubuntu`) - **Home directory path** (e.g., `/home/ubuntu/`) - **Virtual environment path** (e.g., `vllm-env/`) - **Python version** (e.g., `3.12`) - **Internal package structure and line numbers** (e.g., `vllm/entrypoints/openai/chat_completion/api_router.py`) - **Handler function names per endpoint**, enabling precise version fingerprinting This information aids attackers in constructing targeted exploits: environment paths narrow the attack surface, and handler function names + line numbers enable exact version identification even when the `/version` endpoint is disabled. All POST endpoints that accept JSON bodies are affected, including `/v1/chat/completions`, `/v1/completions`, `/tokenize`, and `/detokenize`. ## Workarounds Deploying vLLM behind a reverse proxy that rewrites error response bodies to strip file paths would mitigate this, though it is fragile. ## Remediation Recommendation Two possible fixes (either suffices): **Option A — Fix `validation_exception_handler`:** Construct the error message from `exc.errors()` (the structured Pydantic error list) rather than `str(exc)`. This avoids the traceback-style string entirely. **Option B — Fix `sanitize_message`:** Add a regex to strip `File "...", line \d+` patterns, similar to how memory addresses are already stripped: ```python import re msg = re.sub(r'File ".*?", line \d+, in \w+', '[internal]', msg) ``` Option A is preferred as it addresses the root cause rather than filtering symptoms. ## Environment Tested - vLLM 0.20.1 (pip install, latest stable as of May 2026) - Python 3.12 - Ubuntu 22.04 - Model: Qwen/Qwen2-0.5B (text-only; bug is model-independent) This was fixed here: https://github.com/vllm-project/vllm/commit/e87521626f