GHSA-mcmc-2m55-j8jj

What it actually does

Improper input validation in vLLM allows attacker-controlled API, multimodal, or engine-configuration fields to reach privileged inference code without adequate sanitization or bounds checking. A remote caller can induce undefined behavior in tokenization, media loading, memory allocation, or decoding paths, with high impact to confidentiality, integrity, and availability of the serving process (CVSS 8.8). Effects can include engine crashes, cross-request data leakage from GPU or host memory, and unintended operations on the inference host. This advisory reflects enhanced protection in vLLM for the same class of weakness originally tracked as CVE-2025-62164. Listed Debian linux packages are also in the affected set and require the stated package upgrades.

Why it matters to the business

Production LLM serving can be disrupted or abused: inference APIs may go offline, GPU capacity can be exhausted, prompts and completions from other tenants can leak, and the host running the engine can become a foothold into ML infrastructure. The issue is not in CISA KEV, is not associated with ransomware campaigns, and has no reported public exploit, but it has been public since 8 January 2026 (about 263 days). Unpatched PyPI vLLM releases below 0.13.0 and unfixed Debian linux packages therefore represent overdue residual risk in any environment that exposes an inference API.

How an attack unfolds

An attacker who can reach a vulnerable vLLM OpenAI-compatible HTTP API or internal engine RPC—often with only a valid API token or from a trusted-looking network path—sends requests whose prompts, tool calls, media URLs or blobs, sampling parameters, or structured-output schemas are not fully validated. The engine accepts the payload and executes a code path that assumes well-formed input, producing crashes, leaked state, or unintended host-side behavior. The attacker iterates on responses and process effects until they achieve denial of service, disclosure of other users’ inference data, or further control of the serving process. No named threat actors or ransomware use are reported, and exploit maturity is none, so activity would currently look like targeted API abuse rather than a known commodity campaign.

How to fix it

Upgrade vLLM from PyPI to 0.13.0 or later and rebuild or roll serving images so no runtime still ships an older wheel. On Debian 11, update linux packages to 5.10.127-1 or later; on Debian 12, 13, and 14, update linux packages to 5.18.5-1 or later. Until upgrades are complete, restrict network access to inference endpoints, require strong authentication, disable unused media-URL fetch and multimodal connectors, enforce strict request schema and size limits at an API gateway, and run the engine under least privilege with no unnecessary host mounts or cloud credentials.

How to confirm the fix worked

Confirm the running vLLM package or container SBOM shows version 0.13.0 or newer (for example via pip show vllm or image inventory). On Debian, confirm linux package versions meet 5.10.127-1 (Debian 11) or 5.18.5-1 (Debian 12/13/14). After upgrade, replay previously malformed chat, media, and structured-output requests in a non-production replica and verify they are rejected with controlled errors rather than worker crashes. Verify unused media-fetch and tool features remain disabled and that only authenticated clients can reach the API.

Typical attack path

1. Locate a reachable vLLM HTTP API or worker (direct exposure, ingress, or internal service mesh)
2. Authenticate with a legitimate or stolen API token if the endpoint is not open
3. Enumerate weakly validated fields on chat, completion, embedding, and multimodal or media-fetch routes
4. Submit crafted payloads that bypass incomplete input checks
5. Observe 5xx responses, stack traces, leaked completion content, or worker crashes and refine the payload
6. Abuse resulting engine faults or host-level effects to disrupt service or expand access on the inference host

How to detect it

There is no KEV listing, no ransomware association, and no public exploit, so hunting is for attempted abuse rather than a known implant. Review vLLM, uvicorn/gunicorn, reverse-proxy, and API-gateway logs around OpenAI-compatible routes for repeated 4xx/5xx bursts, stack traces from tokenization or media loading, and single-client traffic that coincides with worker exits. On hosts, look for unexpected restarts of the vLLM API server or engine-core processes, CUDA OOM or segfault patterns, and outbound fetches to unusual URLs if media connectors were enabled. Compare runtime package versions against 0.13.0 and Debian linux fixed versions to distinguish unpatched exposure from confirmed compromise.

What your security team should do

• Treat remaining vLLM versions below 0.13.0 as overdue for patching given 263 days since publication and CVSS 8.8
• Inventory all inference images, wheels, and Debian hosts for vllm < 0.13.0 and for linux packages below the listed fixed versions
• Network-isolate vLLM, require API authentication, and place schema and size validation in front of the API
• Disable unused multimodal, media-URL, and unconstrained structured-output features until patched
• Hunt historical API and process logs for crash loops and anomalous request shapes even though no public exploit is known
• Rebuild and redeploy serving images after upgrade so pinned base layers cannot reintroduce the old wheel