vLLM's OpenAI-compatible API returns raw Python tracebacks on malformed JSON requests, exposing the OS username, home and virtualenv paths, Python version, internal package layout, and endpoint handler names to any unauthenticated caller. The blast radius is real given vLLM's dominance as a self-hosted LLM inference engine, but the exploitation math is modest: EPSS sits at 0.26%, there's no public exploit or Nuclei template, it's not in CISA KEV, and CISA's own SSVC decision is TRACK rather than Act. The value to an attacker is reconnaissance, not direct compromise — CVSS confirms this with C:L/I:N/A:N, no integrity or availability impact. Patch to vLLM 0.26.0, which fixes both the exception handler and the message sanitizer; until then, front the API with a reverse proxy that strips 5xx bodies before they reach clients and monitor for repeated malformed-JSON probes as a recon signal.
What is the risk?
Medium severity (CVSS 5.3) reflecting a confidentiality-only issue with no integrity or availability impact. Attack vector is network-based, unauthenticated, and trivially reproducible (send malformed JSON to a completions/tokenize endpoint) — but the payoff is limited to environment fingerprinting rather than code execution or data exfiltration. EPSS (0.255%) places real-world exploitation likelihood as very low in absolute terms, and the absence of a public PoC, Nuclei template, or KEV listing confirms this isn't being actively weaponized. Risk is elevated primarily by how widely vLLM is deployed as production inference infrastructure and by the fact that zero privileges or interaction are required to trigger it.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | < 0.26.0 | 0.26.0 |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
Upgrade to vLLM 0.26.0 or later, which fixes both validation_exception_handler and sanitize_message to strip traceback-style paths. Until patched, place a reverse proxy or API gateway in front of vLLM that returns generic error bodies on 4xx/5xx rather than passing through vLLM's raw response. Restrict network exposure of inference endpoints to trusted internal networks or authenticated gateways rather than the open internet. Detection: monitor access logs for repeated malformed-JSON POSTs to inference endpoints (a common recon pattern), and audit whether error responses in your environment currently leak filesystem paths by sending a deliberately malformed request and inspecting the response.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-73555?
vLLM's OpenAI-compatible API returns raw Python tracebacks on malformed JSON requests, exposing the OS username, home and virtualenv paths, Python version, internal package layout, and endpoint handler names to any unauthenticated caller. The blast radius is real given vLLM's dominance as a self-hosted LLM inference engine, but the exploitation math is modest: EPSS sits at 0.26%, there's no public exploit or Nuclei template, it's not in CISA KEV, and CISA's own SSVC decision is TRACK rather than Act. The value to an attacker is reconnaissance, not direct compromise — CVSS confirms this with C:L/I:N/A:N, no integrity or availability impact. Patch to vLLM 0.26.0, which fixes both the exception handler and the message sanitizer; until then, front the API with a reverse proxy that strips 5xx bodies before they reach clients and monitor for repeated malformed-JSON probes as a recon signal.
Is CVE-2026-73555 actively exploited?
No confirmed active exploitation of CVE-2026-73555 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-73555?
Upgrade to vLLM 0.26.0 or later, which fixes both validation_exception_handler and sanitize_message to strip traceback-style paths. Until patched, place a reverse proxy or API gateway in front of vLLM that returns generic error bodies on 4xx/5xx rather than passing through vLLM's raw response. Restrict network exposure of inference endpoints to trusted internal networks or authenticated gateways rather than the open internet. Detection: monitor access logs for repeated malformed-JSON POSTs to inference endpoints (a common recon pattern), and audit whether error responses in your environment currently leak filesystem paths by sending a deliberately malformed request and inspecting the response.
What systems are affected by CVE-2026-73555?
This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference, RAG pipelines, agent frameworks.
What is the CVSS score for CVE-2026-73555?
CVE-2026-73555 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 0.42%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049 Exploit Public-Facing Application AML.T0069 Discover LLM System Information AML.T0087 Gather Victim Identity Information Compliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An adversary scanning for exposed LLM inference infrastructure finds an internet-facing vLLM instance and sends a deliberately malformed JSON payload to /v1/chat/completions with no authentication. The server's exception handler serializes the raw exception object, and the sanitizer fails to strip file-path fragments, returning a response that reveals the deployment's OS username, home directory, virtualenv path, Python version, and internal vLLM module structure. The attacker now has a precise environment fingerprint — enough to identify the hosting pattern (e.g., containerized vs. bare-metal, cloud provider conventions embedded in paths), guess the deployment's likely OS user for follow-on credential attacks, or select exploits tuned to the disclosed Python/package versions.
Weaknesses (CWE)
CWE-209 Generation of Error Message Containing Sensitive Information
Primary
CWE-209 Generation of Error Message Containing Sensitive Information
Primary
CWE-209 Generation of Error Message Containing Sensitive Information CWE-209 — Generation of Error Message Containing Sensitive Information: The product generates an error message that includes sensitive information about its environment, users, or associated data.
- [Implementation] Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
- [Implementation] Handle exceptions internally and do not display errors containing potentially sensitive information to a user.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N References
- github.com/advisories/GHSA-hwrm-c4cx-rf4j
- nvd.nist.gov/vuln/detail/CVE-2026-73555
- github.com/vllm-project/vllm/commit/e87521626febe2763f997691d1599de4175f4324
- github.com/vllm-project/vllm/pull/46415
- github.com/vllm-project/vllm/releases/tag/v0.26.0
- github.com/vllm-project/vllm/security/advisories/GHSA-hwrm-c4cx-rf4j
Timeline
Related Vulnerabilities
CVE-2026-61732 10.0 Analysis pending
Same package: vllm CVE-2024-11041 9.8 vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllm CVE-2025-47277 9.8 vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllm CVE-2026-25960 9.8 vllm: SSRF allows internal network access
Same package: vllm CVE-2024-9053 9.8 vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm