vLLM 0.32.0: Eight Advisories, Including SHM Pickle RCE and an EPS Ghostscript Chain

vLLM published eight security advisories (dated October 20, 2026 and added to the GitHub Advisory Database on October 28), all fixed in vLLM 0.32.0. Two are high severity and lead to code execution on the inference host: a forged shared-memory handle that reaches pickle.loads() in a worker, and an EPS image that can reach a vulnerable Ghostscript. The other six are five medium-severity denial-of-service or gate-bypass bugs and one low-severity CORS default. If you serve models with vLLM, run pip show vllm and upgrade to 0.32.0 or later.

For people who run coding agents the relevance is the serving side. Teams that self-host an open-weight model for their agents often run vLLM behind a gateway, and that host typically holds model weights, provider keys and network paths to internal services. We covered the previous vLLM release in two posts, on a request-controlled code_revision RCE and on multimodal denial-of-service bugs. This batch is a separate event, and 0.32.0 supersedes 0.31.0. The tool's page in the Beam CVE database is vLLM.

Quick answers

The two high-severity bugs

CVE-2026-115912: forged SHM handle reaches pickle.loads

GHSA-6757-hggm-hp2w is rated high, CVSS 7.5, and is tracked in the Beam database as CVE-2026-115912. It only applies when the server runs with --mm-processor-cache-type shm.

In that mode the multimodal cache represents a cached item as an address and monotonic_id pair, and the worker treats that pair as authority to read shared memory. The advisory describes how a public scale-out request can carry its own multimodal features.kwargs_data, so a caller can forge an inner carrier that points at attacker-chosen bytes already staged in the ring buffer. The worker deserializes those bytes and reaches pickle.loads().

The chain the reporter used has three steps over ordinary HTTP routes:

1. /v1/chat/completions/render returns a valid feature envelope.
2. /v1/chat/completions stages attacker-chosen bytes into shared memory.
3. /inference/v1/generate submits the forged inner carrier, and the worker unpickles the staged bytes.

The point worth underlining is that this does not need VLLM_ALLOW_INSECURE_SERIALIZATION=1. The advisory states the exploit works with that flag at 0, because it abuses the built-in SHM object deserializer instead of the optional msgpack hook. The reporter's proof used a benign marker gadget and also saw the EngineCore health endpoint fall from 200 to 503 after the forged request. The advisory credits the finding to Patch the Planet, a Trail of Bits and OpenAI collaboration, using GPT-5.5-Cyber. We wrote about that initiative in our Patch the Planet disclosure framework post.

The fix described in the advisory binds each SHM handle to a server-issued capability tied to the cache key, address and monotonic id, and rejects forged carriers at the public scale-out boundary. That suggested design was in a proposed change; the advisory says the issue was fixed in vLLM pull request 59357.

CVE-2026-115915: EPS image to Ghostscript

GHSA-h3rc-j82p-2c3h is rated high, CVSS 8.1, and is tracked as CVE-2026-115915. The advisory is careful about what it claims, and so should we.

vLLM's ImageMediaIO hands image bytes to Pillow's format autodetection with no allowlist of formats. The MIME label on the request does not constrain which decoder runs. An EPS payload labeled image/png therefore reached the host's Ghostscript executable, which Pillow invokes with -dSAFER. On a host with a Ghostscript build affected by the older CVE-2024-29510, which lets crafted PostScript bypass -dSAFER, that becomes command execution with the vLLM process's privileges.

Three details matter for triage:

• It is an N-day chain. The advisory claims no new Ghostscript flaw. Ghostscript lists 10.03.1 as the upstream fixed version, and vLLM's Python requirements do not declare Ghostscript at all, so exposure depends on what is in your host or container image.
• What was reproduced. Command execution ran through the PyPI vllm==0.30.0 wheel's ImageMediaIO.load_base64() with Debian Ghostscript 10.03.0. The HTTP request path was traced in source but not run end to end, and only 0.30.0 was checked.
• A second condition on the same boundary. With Pillow 12.0.0 to 12.2.0, a negative %%BeginBinary count makes Pillow's EPS parser loop (CVE-2026-59203, a Pillow bug). Eight concurrent image loads occupied the connector's eight media-loading threads in the reporter's test. Pillow 12.3.0 rejected the sample.

The advisory says the fix is vLLM pull request 60022.

The five medium-severity bugs

All five are rated medium, CVSS 6.5, and fixed in 0.32.0. Four are denial of service, one is a gate bypass.

Phi-4 audio and DeepSeek-OCR: one request, one dead engine

For Phi-4 multimodal, the audio encoder runs conformer attention in eager mode by default and stores the attention matrix on the module for each of 24 layers. The only limits on audio are a 25 MB file cap and a 600 second decode cap, so a 10-minute clip is legal input. The reporter verified on the official vllm/vllm-openai:v0.31.0 image that a single 19.2 MB silent WAV produced a CUDA out-of-memory error, an EngineDeadError and a dead /health, about six seconds after the request.

For the DeepSeek-OCR family (including deepseek-ai/DeepSeek-OCR, DeepSeek-OCR-2 and baidu/Unlimited-OCR), an inherited guard returns None when torch.sum(pixel_values) == 0. Normalization maps pixel value 0 to exactly -1.0 and 255 to +1.0, so a 1024x1024 image that is half pure black and half pure white sums to exactly zero. The engine-side sanity check then fails. The advisory describes this as a single unauthenticated request under default configuration.

Token ids and templates

The token-id bug is narrow but easy to hit. For models whose vocabulary size is a multiple of 64, such as the Llama-2 family at 32000, the validator accepts id 32000, one past the last embedding row. At tensor-parallel size 1 the embedding lookup does not mask indices, so a pre-tokenized prompt with that id crashes the engine. With tensor parallelism above 1 the id is clamped instead.

The two chat-template bugs link together. --trust-request-chat-template defaults to false and gates request-supplied templates on Chat Completions, render, tokenize and pooling. The Responses endpoint was missing that gate for chat_template_kwargs. The Jinja advisory explains why that matters: the sandboxed environment prevents code escapes, but has no timeout, output cap or loop limit, and the render runs in a thread pool whose max_workers defaults to 1. A short template can wedge every chat-style endpoint for every tenant until restart, and a string-multiplication variant can OOM-kill the API server. The advisory notes the Responses gap makes the attack work in a default vllm serve configuration for an authenticated caller. It also notes a malicious model repository whose tokenizer_config.json carries a hostile template could wedge replicas that load it.

The low-severity one: wildcard CORS

GHSA-vvpg-rrww-wpmh (CVE-2026-115917, CVSS 3.4) is small, but relevant to developer laptops. The OpenAI-compatible server registers CORS middleware with allowed_origins defaulting to ["*"], and does no authentication unless --api-key or VLLM_API_KEY is set. A web page on any origin can send requests to a vLLM server that the victim's browser can reach, such as localhost or an internal VPN address, and read the responses. Credentialed cross-origin requests stay blocked by the default allow_credentials=False, but vLLM uses bearer tokens rather than cookies, so an unauthenticated server is open to any page you visit.

What this means if you run AI coding agents

Most readers of this blog do not operate a vLLM fleet, but plenty run a local or team-hosted vLLM that a coding agent points at. A short checklist:

1. Check the version. Run pip show vllm, or docker image inspect for the container tag, and move to 0.32.0 or later.
2. Set an API key (--api-key or VLLM_API_KEY) on any server that is not strictly local. Most of these bugs need a caller who can reach inference routes.
3. Check for the SHM cache. Search your launch scripts for --mm-processor-cache-type shm. If it is set and you cannot upgrade, we would turn it off. That is our suggestion, not an official workaround.
4. Check Ghostscript. Run gs --version in the image. Anything below 10.03.1 is the vulnerable range named by the advisory for CVE-2024-29510. Also check pip show pillow: 12.3.0 or later rejects the looping EPS sample.
5. Restrict origins. Pass an explicit --allowed-origins list instead of the wildcard, and do not bind the server to an address a browser on a shared network can reach.
6. Watch the logs for EngineDeadError, CUDA device-side assert and out-of-memory messages, a health endpoint that returns 503, and worker processes spawning shells or touch-style children. Repeated engine deaths after a single request are the pattern for the DoS bugs.
7. Do not trust a model repository's templates. Keep --trust-request-chat-template off, and treat a tokenizer_config.json from an unknown repository as input to be reviewed.

What Beam can and cannot do here

Beam does not inspect inference servers, so it cannot detect or block any of these eight bugs. It runs on the developer machine and watches the coding agent: its hooks for Claude Code and Codex can flag credential exposure and destructive commands, and its scanner reviews skills and MCP configs before you run them. If your agent's config points at a self-hosted vLLM URL, that is worth knowing about when you check dependencies for known CVEs. Beam's deny is hook-based, not a kernel sandbox, and its scan is heuristic.

Related incidents and context

Self-hosted inference endpoints are an attractive target even without a bug. Symantec's write-up on attackers hunting exposed AI endpoints is summarized in our post on LLMjacking and exposed AI endpoints, and the gateway side had its own October advisories in LiteLLM CVE-2026-114612. The pattern across all of them: the AI serving layer inherits the old rules for network services, with authentication first, least privilege second, and patches third.

Frequently asked questions

Which vLLM versions are affected by the October 28 advisories?

All eight list vLLM below 0.32.0 as vulnerable and 0.32.0 as the first patched version. Some have a narrower floor: the DeepSeek-OCR bug starts at 0.11.1, the Responses API bypass at 0.16.0 and the Jinja rendering DoS at 0.19.0.

Which two advisories are high severity?

CVE-2026-115912 (CVSS 7.5) is a forged shared-memory handle that reaches pickle.loads() in the worker. CVE-2026-115915 (CVSS 8.1) is an EPS image that can reach Ghostscript and, on a vulnerable build, execute commands.

Does the SHM pickle bug need VLLM_ALLOW_INSECURE_SERIALIZATION?

No. The advisory says it is reachable with VLLM_ALLOW_INSECURE_SERIALIZATION=0. It needs --mm-processor-cache-type shm and a caller who can reach the inference routes, so API-key authentication matters.

Am I safe from the Ghostscript chain if Ghostscript is not installed?

The advisory says deployments without Ghostscript, or with a build fixed for CVE-2024-29510 (10.03.1 upstream), are not affected by the command-execution chain. Pillow 12.0.0 to 12.2.0 still exposes a separate EPS denial of service.

What can I do if I cannot upgrade yet?

Set an API key, keep the server off untrusted networks, avoid the shm multimodal cache type, and restrict allowed origins. These are our suggestions based on the preconditions in the advisories, not official workarounds.

Can Beam detect or block these?

No. Beam runs on a developer machine and watches coding agents; it does not inspect inference servers. It can flag risky agent actions locally and scan skill and MCP configs.

Sources

• GHSA-6757-hggm-hp2w, GHSA-h3rc-j82p-2c3h, GHSA-8397-8qf6-f2gm, GHSA-gq5q-89c7-vhvx, GHSA-q97c-p368-75c4, GHSA-x567-49g5-p4cf, GHSA-542m-9234-8gvf, GHSA-vvpg-rrww-wpmh
• Pillow advisory GHSA-pg7v-jwj7-p798
• Ghostscript CVE details

Versions, severities and advisory details are accurate as of October 28, 2026. We have not reproduced these bugs ourselves; the exploitation details are the reporters' accounts in the advisories. Check the vLLM advisories page for later changes.