CVE-2026-73555: vLLM: verbose errors leak host paths & usernames

GHSA-hwrm-c4cx-rf4j MEDIUM
Published August 13, 2026
CISO Take

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.

Sources: NVD EPSS GitHub Advisory ATLAS

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?

Recon & entry
Attacker identifies an internet-facing vLLM OpenAI-compatible API and sends a deliberately malformed JSON request without authentication.
AML.T0049
Information disclosure
The unsanitized exception handler returns a traceback revealing OS username, home/venv paths, Python version, and internal package structure.
AML.T0069
Environment fingerprinting
Attacker uses the disclosed paths and versions to profile the deployment (hosting pattern, likely OS user, software versions) for follow-on targeting.
AML.T0087
Follow-on attack staging
Fingerprint data informs selection of version-specific exploits or credential/social-engineering attempts against the identified environment.
AML.T0106

What systems are affected?

Package Ecosystem Vulnerable Range Patched
vLLM pip < 0.26.0 0.26.0
92.7K 95 dependents Pushed 5d ago 26% patched ~47d to patch Full package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1
5.3 / 10
EPSS
0.4%
chance of exploitation in 30 days
Higher than 34% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI None
S Unchanged
C Low
I None
A None

What should I do?

1 step
  1. 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?

Decision Track
Exploitation none
Automatable Yes
Technical Impact partial

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:

ISO 42001
A.6.2.6 - Information security in the AI system life cycle
NIST AI RMF
MANAGE 4.1 - AI system risk monitoring and response
OWASP LLM Top 10
LLM02 - Sensitive Information Disclosure

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

model servingLLM inferenceRAG pipelinesagent frameworks

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application
AML.T0069 Discover LLM System Information
AML.T0087 Gather Victim Identity Information

Compliance Controls Affected

ISO 42001: A.6.2.6
NIST AI RMF: MANAGE 4.1
OWASP LLM Top 10: LLM02

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: 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

Timeline

Published
August 13, 2026
Last Modified
September 4, 2026
First Seen
August 13, 2026

Related Vulnerabilities