CVE-2026-73555
vLLM: Unauthenticated Internal Path and Username Disclosure via Validation Error Messages
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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- Low
- Integrity
- None
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
5.3
vLLM: Unauthenticated Internal Path and Username Disclosure via Validation Error Messages
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.
- Record
CVE-2026-73555- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - Weakness
- CWE-209
- Updated
- 2026-11-02
EUVDEUVD-2026-58053
5.3
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.
- Record
EUVD-2026-58053- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-hwrm-c4cx-rf4j
5.3
vLLM: Unauthenticated Internal Path and Username Disclosure via Validation Error Messages
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:
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
- Record
GHSA-hwrm-c4cx-rf4j- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - Weakness
- CWE-209
- Updated
- 2026-11-02
NVD
5.3
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.
- Record
CVE-2026-73555- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - Weakness
- CWE-209
- Updated
- 2026-11-02
OSV
5.3
vLLM: Unauthenticated Internal Path and Username Disclosure via Validation Error Messages
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.
- Record
CVE-2026-73555- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - Weakness
- CWE-209
- Updated
- 2026-11-04
OSVGHSA-hwrm-c4cx-rf4j
5.3
vLLM: Unauthenticated Internal Path and Username Disclosure via Validation Error Messages
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:
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
- Record
GHSA-hwrm-c4cx-rf4j- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - Weakness
- CWE-209
- Updated
- 2026-11-02
OSVPYSEC-2026-3937
5.3
vLLM: Unauthenticated Internal Path and Username Disclosure via Validation Error Messages
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:
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
- Record
PYSEC-2026-3937- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
vllmPyPI |
before 0.26.0 | 0.26.0 |
vllmPyPI |
before 0.26.0, plus listed versions 0.0.10.1.00.1.10.1.20.1.3 Show 45 moreShow less0.1.40.1.50.1.60.1.70.10.00.10.10.10.1.10.10.20.11.00.11.10.11.20.12.00.13.00.14.00.14.10.15.00.15.10.16.00.17.00.17.10.18.00.18.10.19.00.19.10.2.00.2.10.2.1.post10.2.20.2.30.2.40.2.50.2.60.2.70.20.00.20.10.20.20.21.00.22.00.22.10.23.00.24.00.25.00.25.10.3.00.3.1 |
0.26.0 |
History
| Recorded | Changed | Sources |
|---|---|---|
| facts | OSV | |
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-73555 is a medium vulnerability (CVSS 5.3) in Vllm, published August 13, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.41%, the 35th percentile. Fixed in vllm 0.26.0.
References
github.com/vllm-project/vllm/security/advisories/GHSA-hwrm-c4cx-rf4j
github.com/vllm-project/vllm/pull/46415
github.com/vllm-project/vllm/commit/e87521626febe2763f997691d1599de4175f4324
github.com/vllm-project/vllm/releases/tag/v0.26.0
nvd.nist.gov/vuln/detail/CVE-2026-73555
github.com/advisories/GHSA-hwrm-c4cx-rf4j
github.com/CVEProject/cvelistV5/tree/main/cves/2026/73xxx/CVE-2026-73555.json
github.com/vllm-project/vllm
pypi.org/project/vllm
Left out here: 42 versions. The JSON record has them.