CVE-2026-73555: Environment and Information Disclosure via Exception Handling in vLLM

vLLM is a high-performance open-source inference engine designed for serving Large Language Models. In typical deployment topologies, vLLM exposes an HTTP REST API server compliant with OpenAI endpoints. This API boundary forms the primary external attack surface, managing unauthenticated incoming client requests that are parsed into internal structured payloads.

Because these endpoints are accessible directly over the network, robust input validation and error handling are critical security boundaries. CVE-2026-73555 describes an information disclosure vulnerability (CWE-209) residing within this request validation layer. The flaw allows unauthenticated remote users to trigger structured exceptions that leak extensive host metadata.

When a malformed request is processed, the system produces validation tracebacks rather than sanitized client errors. This leakage exposes absolute directory structures, underlying package frameworks, system configuration states, and active local usernames. This reconnaissance metadata simplifies target environment profiling for subsequent attacks.

The core of the vulnerability lies in how vLLM handles request parsing failures via its FastAPI and Pydantic architecture. When incoming payloads fail validation checks, Pydantic raises a RequestValidationError exception. FastAPI's routing middleware intercepts this exception and processes it through a custom validation handler.

Prior to version 0.26.0, the handler in vllm/entrypoints/serve/utils/server_utils.py converted the raw exception directly into a string representation using str(exc). Under default FastAPI behavior, string conversion of a validation exception serializes the entire contextual route environment. This trace information contains internal application execution paths and local filesystem variables.

Furthermore, the helper library intended to filter sensitive outputs was functionally insufficient. The sanitize_message routine was only designed to strip memory address pointers from object representations using a basic regular expression. It did not parse or neutralize file directories, active operating system paths, or local file trace logs.

The structural modifications implemented in the patch address both the exception formatting architecture and the fallback mitigation layers.

Below is a comparison of the vulnerable error-generation logic versus the patched approach inside vllm/entrypoints/serve/utils/server_utils.py:

# VULNERABLE APPROACH
async def validation_exception_handler(req: Request, exc: RequestValidationError) -> Response:
    # Raw string conversion of 'exc' serializes FastAPI's route traceback contexts
    exc_str = str(exc)
    errors_str = str(errors)
    if errors and errors_str and errors_str != exc_str:
        message = f"{exc_str} {errors_str}"
    else:
        message = exc_str
 
# PATCHED APPROACH
async def validation_exception_handler(req: Request, exc: RequestValidationError) -> Response:
    # Reconstructs errors using structured fields from exc.errors() instead of str(exc)
    if errors:
        count = len(errors)
        label = "error" if count == 1 else "errors"
        message = f"{count} validation {label}:\n"
        message += "".join(f"  {err}\n" for err in errors)
        message = message.rstrip()
    else:
        message = "Validation error"

Additionally, the patch hardens the fallback mechanism inside vllm/entrypoints/serve/utils/api_utils.py to strip out persistent filesystem details:

def sanitize_message(message: str) -> str:
    """Strip memory addresses, tracebacks, and file paths from error messages."""
    message = re.sub(r" at 0x[0-9a-f]+>", ">", message)
    # Strips raw Python traceback patterns
    message = re.sub(r'\n?\s*File "[^"]+", line \d+, in \S+(\n\s+.*)?', "", message)
    # Filters common base directories
    message = re.sub(
        r"/(?:home|usr|opt|var|tmp|root|lib|mnt|srv)(?:/[\w.\-]+)+", "<path>", message
    )
    # Fallback absolute path replacement
    message = re.sub(r"(?:/[\w\-]+)+/[\w\-]+\.\w+", "<path>", message)
    return message.strip()

The following diagram tracks the processing sequence of a malformed client request through the application logic, highlighting how environmental details are exposed during error generation.

Exploitation of CVE-2026-73555 is straightforward and does not require complex payload mechanics. An attacker targeting the /v1/chat/completions endpoint can purposely submit invalid data types to force a validation failure.

For example, the endpoint expects the messages attribute to contain a list of objects. Transmitting a scalar string instead triggers a validation failure, prompting the server to formulate an error response. Because authentication is often bypassed or absent on these standard serving endpoints, any client on the network interface can generate this payload.

The resulting HTTP 422 Unprocessable Entity response returns the path structure of the virtual environment, the python system engine details, and the local shell username. This allows external threat actors to profile the underlying infrastructure without writing to disk or provoking system alerts.

While CVE-2026-73555 is assigned a CVSS score of 5.3 (Medium) due to its read-only impact, its role in a broader attack chain is substantial. Identifying absolute paths and system account names removes key barriers to local privilege escalation or sandbox escape.

Knowing that an instance runs in /home/deployer/vllm-env/ rather than a restricted system container allows attackers to design path-traversal scripts and locate configuration repositories. It also reveals file system permissions, package versions, and operational boundaries.

In environments utilizing containers, this leak compromises the confidentiality of host-mount directories. Because AI infrastructure is frequently deployed in cloud-managed nodes with elevated privileges, exposing the structural design of these endpoints increases the severity of adjacent host exploits.

The primary resolution is upgrading the installation to vLLM version 0.26.0 or higher. This modifies the exception formatter to avoid stringifying raw tracebacks.

However, potential gaps remain in the fallback validation logic. The patterns within sanitize_message rely entirely on Unix-like directory layouts. If vLLM is executed on a native Windows server, backslash-separated absolute directory paths (such as C:\Users\Administrator\vllm\) will not match the current regular expression layout and will still leak to remote users.

Furthermore, non-standard Unix mount directories like /app, /workspace, or /code are not targeted by the default pattern unless they contain a file extension. These omissions could allow some environments to remain partially vulnerable if errors escape the primary validation handler.