vLLM 0.32.0 Fixes Ghostscript RCE and Engine-Crash Flaws

If you run your own inference on vLLM and the image is older than 0.31.0, one request from anyone who can reach the server can take the engine down for every tenant on it. Another can leave it hung while your health check still reports 200. If that image also has Ghostscript installed and serves an image-capable model, a crafted picture can run code as the vLLM process. vLLM published the fixes across v0.31.0 on October 5 and v0.32.0 on October 18, and the advisories followed between October 6 and October 20. The upgrade target is 0.32.0, and the container rebuild matters as much as the version bump.

The project's security advisory list now runs to 12 pages, and its first page alone carries ten advisories published between September 23 and October 20. Most are rated Moderate. A Moderate rating describes one bug in isolation. On a shared GPU endpoint behind an internal gateway, a single bad request taking out everyone's in-flight work is the outage your on-call team gets paged for.

---

Which vLLM Advisories Should You Patch First?

Patch the two code-execution paths first, then the engine crashes, because the RCE bugs depend on configuration you can check in minutes and the crashes affect almost everyone.

Advisory	What one request can do	Rating	Fixed in
GHSA-h3rc-j82p-2c3h (CVE-2026-115915)	Run code through Ghostscript via a disguised EPS image	High, CVSS 8.1	0.32.0
GHSA-h3rc-6mm3-gc2m	Load attacker-chosen processor code when trust_remote_code is on	High, CVSS 8.1	0.31.0
GHSA-rhcx-5729-88vg	Crash EngineCore and drop co-tenant requests via prompt_logprobs	High, CVSS 7.7	0.31.0 (see caveat below)
GHSA-4xqp-c3mv-qff7	Hang the engine with an oversized min_tokens while /health stays green	Moderate, CVSS 6.5	0.31.0
GHSA-q97c-p368-75c4 (CVE-2026-115916)	Crash the engine with one out-of-vocabulary token ID	Moderate, CVSS 6.5	0.32.0
GHSA-vvpg-rrww-wpmh (CVE-2026-115917)	Let any web page call an unauthenticated server through a user's browser	Low, CVSS 3.4	0.32.0

Ratings are the ones vLLM's own advisories carry as of October 27, 2026. Third-party databases score some of these higher, which is covered below.

How Does an Image Turn Into Code Execution?

vLLM 0.30.0 handed attacker-supplied image bytes to Pillow's format autodetection with no allowlist, so a file labelled image/png that is really EPS reaches Pillow's EPS handler, which calls the host's Ghostscript binary. That is the finding in GHSA-h3rc-j82p-2c3h, rated High at CVSS 8.1.

Code execution needs a second, older bug. On a host whose Ghostscript is affected by CVE-2024-29510, a format string flaw in Ghostscript 9.50 through 10.03.0 that bypasses the -dSAFER sandbox, the EPS file can run commands with the vLLM process's privileges. Ghostscript fixed that in 10.03.1 on May 2, 2024. The reporter reproduced command execution at the loader level using the PyPI wheel, Pillow 12.3.0 and Debian's Ghostscript 10.03.0, and traced the full HTTP path in source without testing it end to end.

vLLM's requirements do not install Ghostscript. Your base image might. A CUDA image built on a general-purpose distro with document tooling, or one that someone extended for a PDF-ingest sidecar, is the kind that carries it.

The same advisory describes a Pillow-only denial of service, CVE-2026-59203, in Pillow 12.0.0 through 12.2.0: a negative byte count in an EPS file makes the parser loop inside Image.open(). In the reporter's test, eight concurrent malicious loads occupied every media-loading thread and blocked a normal request. vLLM 0.30.0 left Pillow unpinned, so an existing environment can keep the bad version after you upgrade vLLM alone. The 0.32.0 fix, listed in the release notes as "untrusted images are limited to raster formats" (#60022), closes the EPS path. Pillow 12.3.0 or later closes the loop.

When Does trust_remote_code Become Remote Code Execution?

The second RCE matters only if you serve a multimodal model with --trust-remote-code enabled, which is off by default. Per GHSA-h3rc-6mm3-gc2m, versions from 0.7.3 up to 0.31.0 forwarded a request's mm_processor_kwargs.code_revision value to Transformers, so a client could choose which revision of the model's dynamic processor code got imported. The model revision you pinned and reviewed stays pinned while the processor code under it changes.

The attacker also has to control a revision in the model repository, such as a Hugging Face pull-request ref where a repo allows them. That is a real bar, and teams that mirror weights into a private registry are mostly past it. The detail that should worry you is the endpoint. The advisory says vLLM's authentication middleware guards /v1, /v2, /inference and /cohere, and that /tokenize stays unauthenticated even with --api-key set unless a proxy in front of it protects it.

There is a naming mess to know about. vLLM's advisory lists no CVE and rates it 8.1. The record SecurityOnline publishes as CVE-2026-114053 cites the same GHSA, and scores it 9.2 Critical under CVSS 4.0. The scanner your security team runs may flag it under the CVE ID at Critical, while vLLM's page says High. It is one bug, and 0.31.0 fixes it.

---

Why Do Crash Bugs Matter More on a Shared Endpoint?

Every crash advisory in this batch takes out the whole engine, so on a multi-tenant endpoint one team's bad request becomes every team's outage. The advisories are specific about the mechanics.

The cross-tenant crash in GHSA-rhcx-5729-88vg affects deployments that use a KV connector (LMCache, NIXL, SharedStorage, P2pNccl, Offloading, MultiConnector or a custom subclass). A request with prompt_logprobs, or echo=true with logprobs, against a connector-cached prefix makes the decoder read uninitialized memory and raise OverflowError, which kills EngineCore and drops "every in-flight request on that engine," other tenants' included. The local prefix cache is not affected. Strix's entry for CVE-2026-116180 carries the same description at CVSS 7.7 and lists versions from 0.8.5 up to 0.31.0. The advisory page contradicts itself: it lists 0.31.0 as patched while its text says the fix "has not landed upstream." Until you confirm the fix in your build, use the advisory's workarounds: drop --kv-transfer-config, or strip prompt_logprobs, logprobs and echo at your gateway.

The silent hang is in GHSA-4xqp-c3mv-qff7: one call to /inference/v1/generate with max_tokens null and a huge min_tokens kills the engine's input thread. The process keeps running, later requests hang, and /health returns 200 because the health check only looks for a recorded error and none is recorded. The advisory notes this endpoint is mounted by default in v0.29.0 and unauthenticated unless --api-key is set. Kubernetes will not restart a pod whose liveness probe passes, so this one waits for a human to notice.

For models whose vocabulary size is a multiple of 64, such as Llama-2's 32,000, GHSA-q97c-p368-75c4 shows an off-by-one: token ID 32000 passes validation, and with tensor parallelism of 1 it triggers a CUDA device-side assert that crashes the engine. With tensor parallelism above 1 the ID is clamped and the likely result is wrong output. Any client that can send pre-tokenized prompts to /v1/completions can trigger it.

These are not the first serious vLLM flaws. In April 2025, CVE-2025-32444 scored 10.0 for unauthenticated pickle deserialization in the Mooncake integration, fixed in 0.8.5. That one also hit only teams using one optional component. The October batch differs in reach: the hang and the token ID crash need no optional integration.

What Breaks When You Upgrade?

The upgrade changes request handling, so test it against your real clients before you roll it out. The release notes list several breaking changes.

• 0.31.0 rejects per-request mm_processor_kwargs and media_io_kwargs unless you start the server with --trust-request-mm-kwargs (#58830). Any client that tunes image or video preprocessing per request will start getting errors. Turning the flag back on reopens the surface you just closed, so move those settings to server config instead.
• 0.32.0 restricts default CORS origins (#61009). Before it, the OpenAI-compatible server allowed every origin, and the CORS advisory explains that a malicious page could then list models and run chat completions through a user's browser against an internal or localhost server with no API key. A browser-based internal tool that calls vLLM directly will break until you configure its origin.
• 0.32.0 drops Python 3.10 (#60402) and no longer reserves max_tokens from the context window (#57035). The second one can change which long-context requests succeed.
• 0.31.0 removes tokenizer_mode="slow" (#58545).

If you consume vLLM through a vendor distribution such as Red Hat AI, a KServe runtime or an air-gapped bundle, the upstream version number does not tell you whether the fix is in. The cross-tenant crash reporter asked for pre-disclosure notice to LMCache, NIXL and NVIDIA Dynamo, llm-d, vLLM Production Stack and KServe, which is a reasonable list of vendors to ask.

---

What to Do About It

This Week:

1. Inventory every vLLM image you run, including the ones inside vendor runtimes and notebooks, and record the vLLM, Pillow and Ghostscript versions in each. pip show vllm pillow and gs --version inside the container is enough.
2. Remove Ghostscript from inference images that have no reason to carry it. Where it must stay, require 10.03.1 or later.
3. Put /tokenize and /inference behind your gateway's authentication. The advisories say --api-key alone does not cover /tokenize.
4. Check for --trust-remote-code on multimodal models. If it is on, upgrade those servers first.

This Month:

1. Upgrade to 0.32.0 with Pillow 12.3.0 or later, after a staging run against your real client traffic to catch the mm_processor_kwargs, CORS and max_tokens changes.
2. Replace /health-only liveness probes with a probe that sends a short real generation request and fails on timeout. The min_tokens hang proves a 200 from /health is not evidence the engine can serve.
3. If you run a KV connector, confirm the logprobs fix is in your build or strip prompt_logprobs, logprobs and echo at the gateway.

Before Your Next Platform Review:

1. Decide whether shared multi-tenant endpoints are acceptable for workloads that cannot tolerate another team's outage. Separate engines per tenant tier cost GPU capacity, and they are the only way to keep one tenant's crash from dropping another tenant's requests.
2. Subscribe your platform team to vLLM's GitHub security advisories and set a patch SLA. Ten advisories in four weeks is the current pace.

The Bottom Line

Self-hosted inference servers now get advisory batches like any other network-facing server, many of them denial of service and most fixed by an upgrade that also breaks something. The teams that came through the LiteLLM compromise in October already know the pattern for proxies and gateways. vLLM is the runtime most self-hosting teams default to, as our runtime comparison recommends, and the air-gapped stacks built on it need patch pipelines that reach inside the air gap. If you priced self-hosting against APIs in our break-even analysis, add the patch cadence to the operating cost. Weight provenance matters too: the code_revision bug is one more reason to serve models from a private registry instead of a live Hugging Face ref.

Start with gs --version inside your inference containers.

Continue Reading

• LiteLLM's October 21 Compromise Puts Provider Keys at Risk
• vLLM vs TensorRT-LLM vs SGLang: Default to vLLM
• Best Air-Gapped LLM Stack: Apache Weights on vLLM Beat NVIDIA's Fee
• Hugging Face Alternatives: Cache the Hub, Sign at the Door
• Together AI and Bedrock beat self-hosted gpt-oss-120b on cost
• Random Eviction Matched the Scorers. Protect the Prompt.