Announced 28 Oct 2026 · Sources checked
The Ghostscript chain
The Register reported on 28 October 2026 that vLLM shipped version 0.32.0 patching eight CVEs, including CVE-2026-115915 (CVSS 8.1), handled via GitHub advisory GHSA-h3rc-j82p-2c3h. In vLLM 0.30.0, `ImageMediaIO` passes attacker-controlled image bytes to Pillow's `Image.open(BytesIO(data))` without restricting the accepted format. The MIME label does not constrain decoder selection: an EPS payload labeled `image/png` reaches the host's Ghostscript executable.On a host with Ghostscript affected by CVE-2024-29510 — a known sandbox escape — this exposes command execution with the vLLM process's privileges. The advisory reproduced the loader-level execution through the PyPI wheel's actual `ImageMediaIO.load_base64()` implementation using Debian Ghostscript 10.03.0. Exploitation requires an image-capable request path, a caller able to reach it and a vulnerable host Ghostscript build.
The SHM forgery chain
The second major vulnerability, GHSA-6757-hggm-hp2w (CVSS 8.8), targets vLLM's multimodal shared-memory processor cache. When `--mm-processor-cache-type shm` is enabled, the cache represents a cached item with an `address` and `monotonic_id` pair and treats that pair as authority to dereference shared memory in the worker.
A public scale-out request can supply its own multimodal `features.kwargs_data`, so an authenticated caller can forge an inner SHM carrier that points at attacker-controlled bytes already staged in the ring buffer. The worker then reaches `pickle.loads()` while deserializing the forged object — and this is reachable through ordinary public HTTP routes without requiring `VLLM_ALLOW_INSECURE_SERIALIZATION=1`. The disclosed live chain used `/v1/chat/completions/render` to obtain a valid feature envelope, `/v1/chat/completions` to stage bytes into SHM and `/inference/v1/generate` to submit the forged carrier.
The remaining advisories
The full set of eight CVEs includes the two high-severity chains described above plus six additional advisories covering denial-of-service through crafted inputs, information disclosure paths and dependency-related vulnerabilities in Pillow and other libraries in the vLLM dependency graph. All are fixed in 0.32.0.
vLLM strongly recommends upgrading via `pip install vllm==0.32.0` or pulling the updated Docker images. Deployments without Ghostscript or with a build fixed for CVE-2024-29510 are not affected by the EPS execution chain; deployments without `--mm-processor-cache-type shm` are not affected by the SHM forgery path.
What it means
vLLM is one of the most widely deployed open-source LLM serving engines, running inference for production AI applications across cloud and on-premises deployments. These advisories demonstrate two real attack surfaces that affect inference infrastructure: multimodal image-processing pipelines and model-worker inter-process communication.
The EPS-to-Ghostscript chain is a reminder that even simple image-input support introduces code-execution paths through OS-level dependencies that few operators audit. The SHM forgery is a more design-level weakness: the shared-memory cache trusted a caller-supplied handle as authority, which is a trust-boundary violation. Both are fixed in the release, but the class of vulnerability — trusting inference-server IPC — is likely to reappear in other serving frameworks.
Caveats and what to watch
Both exploit chains require specific preconditions: vulnerable Ghostscript or the shm processor cache enabled. Not every deployment is affected by each chain. The published CVSS scores reflect the worst-case impact under those conditions.
Watch whether other LLM serving frameworks (TensorRT-LLM, TGI, SGLang) disclose similar trust-boundary issues in their image or IPC handling. Watch for third-party security audits of the vLLM codebase following these disclosures.
Deployment impact
For teams running vLLM in production, the immediate action is to upgrade. The two high-severity chains affect different configurations, which means the set of vulnerable deployments is broader than either single path would suggest: any deployment serving multimodal requests with image input on a host that has Ghostscript is exposed to the EPS chain, and any deployment with the shm processor cache enabled is exposed to the SHM forgery.
The practical advice for operators is to check both configurations and upgrade regardless: vLLM recommends pinning to 0.32.0 across all deployments even if neither vulnerable path seems active today, because the full advisory set includes additional DoS and disclosure CVEs that may apply in edge conditions. The official Docker images were updated in the same release cycle.
The broader vulnerability class
Inference serving frameworks are a class of infrastructure that has received less security attention than web servers or databases, despite handling the same attack surface — public HTTP endpoints, image upload, inter-process communication — plus new surfaces like model weight access, token-generation manipulation and shared-memory processor caches. The vLLM advisories are among the most detailed disclosure of inference-infrastructure vulnerabilities yet published.
The SHM forgery is especially interesting as a trust-boundary bug: the cache design assumed that only the vLLM process itself would write SHM handles, so it did not validate that a handle presented by a client request referred to the cache's own allocations. That assumption is common in high-performance serving code, and similar patterns probably exist in other frameworks that use shared memory for multimodal data.
Caveats
The exploit chains were disclosed by security researchers who reproduce vulnerabilities — the advisories describe the technical path but are not evidence of active exploitation in the wild. CISA has not issued an alert beyond the standard CVE process.
Deployments that do not serve image-capable models or do not use the shm processor cache are not affected by the corresponding specific chains, but all deployments should upgrade for defense in depth against the full advisory set.
Common questions
How many CVEs did vLLM 0.32.0 patch?
Eight, including two high-severity RCE chains and six additional denial-of-service and information-disclosure advisories.
Do all deployments need to upgrade?
Yes — vLLM recommends upgrading regardless of configuration, because the advisory set covers multiple attack surfaces.
What should operators do?
Upgrade to vLLM 0.32.0 via pip or Docker: `pip install vllm==0.32.0`.
Sources & further reading
How this story was made
Written by Kristian Kostov with AI assistance and checked against the linked sources. Company performance claims are attributed to the company. Analysis reflects AiLookout’s interpretation; we have not independently tested the products discussed. The cover is an AI-generated editorial illustration, not a photograph or evidence of an actual event.
Our editorial standards





