vLLM — CVE-2026-54236 Exposes Sensitive Data via Incomplete Log Sanitization Fix
AI relevance: vLLM is the dominant open-source LLM inference server — information leaks in its API routes can expose memory addresses, internal state, and potentially model weights or API keys to anyone who can trigger an exception.
- CVE-2026-54236 (CWE-532: Insertion of Sensitive Information into Log File) was published June 22, 2026. It affects vLLM versions prior to v0.23.1rc0.
- The vulnerability is an incomplete fix for a prior information leak. Certain API routes and WebSocket handlers bypass the global exception sanitization, causing memory addresses and other sensitive data to appear in logs and error responses.
- The CVE was reserved on June 12, 2026 and published June 22. It is assigned to the vllm-project/vllm GitHub repository.
- This comes alongside CVE-2026-41523 (CWE-94: Code Injection, CVSS 9.8) which allows unauthenticated arbitrary code execution on vLLM servers running versions below 0.22.0, and CVE-2026-54235 involving NaN/float validation gaps enabling GPU kernel manipulation.
- vLLM serves as the inference backbone for thousands of production AI deployments — from startups to enterprise model serving. Any information leak in this layer is high-leverage for attackers.
- The bypass pattern (specific routes skipping global sanitization) is a recurring anti-pattern in AI infrastructure: a security wrapper is applied at one layer, but exceptions in deeper handlers escape through unguarded paths.
- Combined with the code injection CVE, operators face a scenario where attackers can both execute code and extract sensitive runtime data from vLLM instances.
Why it matters
vLLM instances typically hold or process API keys (OpenAI, Anthropic, etc.), model weights, and inference data from multiple tenants. Memory address leaks can aid exploitation of other vulnerabilities (ASLR bypass). The incomplete-fix pattern suggests that the original sanitization was treated as a cosmetic issue rather than a security boundary — a common mistake in ML infrastructure where ops teams prioritize throughput over defense-in-depth.
What to do
- Upgrade vLLM to v0.23.1rc0 or later immediately to address CVE-2026-54236.
- If running below v0.22.0, prioritize the code injection fix (CVE-2026-41523) — it is CVSS 9.8 with no authentication required.
- Audit vLLM log outputs and error responses for memory addresses, API keys, or other sensitive data. Treat logs as potentially public.
- Ensure global exception handlers cover ALL routes including WebSocket endpoints — test by triggering errors on every API path.
- Run vLLM behind a reverse proxy that strips internal error details before they reach clients.
- Rotate any API keys or credentials that were accessible to vLLM processes if you suspect log exposure.