vLLM 0.32.0: eight CVEs at once, including one allowing code execution via an EPS image and Ghostscript

vLLM 0.32.0: eight CVEs at once, including code execution via an EPS image and Ghostscript

🔎 Eight advisories the same day, and plenty of servers that won't budge

On October 20, 2026, the vLLM project published eight security advisories at once, all fixed in version 0.32.0. Added to the GitHub Advisory Database on October 28, they are part of a series that now spans 12 pages of advisories on the project's repository, including 10 published between September 23 and October 20. This is no longer an isolated incident: it's a pattern.

The most serious of the bunch, CVE-2026-115915 (CVSS 8.1, High), allows a mere user of an inference endpoint to execute code on the host machine — by sending an EPS image disguised as a PNG, which ends up in the hands of a vulnerable Ghostscript installed on the host. A single request, code executed with the privileges of the vLLM process.

If you self-host vLLM — to serve a model internally, power an agent, or simply avoid API costs — this article is your checklist. We detail the three most significant CVEs, the rest of the batch, and above all the concrete update procedure. Zero alarmism: the facts, the versions, the commands.

Main sources: the analysis from beri.net, the NVD entry for CVE-2026-115915, and the security advisories page of the vLLM project.

The Essentials

• CVE-2026-115915 (CVSS 8.1, High): an EPS payload labeled image/png bypasses Pillow's format detection and reaches the host's Ghostscript executable. On a host affected by CVE-2024-29510, this yields a Ghostscript sandbox escape and command execution with the vLLM process's privileges. Fixed in 0.32.0.
• CVE-2026-115916 (CVSS 6.5): an off-by-one error in vllm/tokenizers/hf.py lets an out-of-vocabulary token ID through, causing a CUDA device-side assert and a full engine crash. Fixed in 0.32.0.
• CVE-2026-115917 (CVSS 3.4): wildcard CORS by default (allowed_origins = *) on the OpenAI-compatible server, with no authentication unless --api-key or VLLM_API_KEY is configured. Any web page can call your server from your users' browsers. Fixed in 0.32.0.
• CVE-2026-115912 (CVSS 7.5, High): a forged shared memory handle reaches pickle.loads — a second path to arbitrary code execution. Fixed in 0.32.0.
• Version 0.32.0 covers the entire October batch. The older advisories (RCE via code_revision, hang via min_tokens, cross-tenant crash via logprobs) were fixed in 0.31.0. If you stayed on 0.30.x, you're accumulating both waves.
• Quick checklist: pip show vllm (aim for ≥ 0.32.0), gs --version (10.03.1 or newer, otherwise your host is vulnerable to the sandbox escape), Pillow ≥ 12.3.0, and an API key across the board.

Recommended tools

To audit and secure a self-hosted inference stack, here is what we use and recommend:

CVE-2026-115915: a disguised EPS image that ends in code execution (CVSS 8.1)

Direct answer: yes, a user of your API can execute code on your server by sending a single malformed image — if your host runs a vulnerable Ghostscript. This is the most serious CVE of the bunch, rated High with a CVSS of 8.1 according to NVD.

The exploitation chain, step by step

The problem lies in vLLM's ImageMediaIO module, present at least since version 0.30.0. When an image arrives via a multimodal request, vLLM passes the raw bytes to Pillow's automatic format detection — without an allowlist. Pillow examines the bytes, guesses the format, and delegates decoding to the appropriate handler.

The trap: PostScript and EPS are formats that Pillow knows how to recognize, but doesn't decode itself. It delegates to the Ghostscript executable installed on the host. An attacker can therefore send an EPS payload while claiming it is an image/png in the request metadata. Pillow's automatic detection sees the EPS bytes, delegates to Ghostscript, and your server executes user-supplied PostScript.

That's already bad. But it becomes critical when the host's Ghostscript is itself vulnerable. The scenario reproduced in the GitLab advisory's analysis combines vLLM with a Debian Ghostscript 10.03.0 affected by CVE-2024-29510 — a known Ghostscript sandbox escape. Result: command execution with the privileges of the vLLM process. On most Docker deployments, this means root in the container, and often well beyond that if the mounts are permissive.

Why it's serious even without internet exposure

Many teams think "my vLLM is only exposed internally, so no risk." Two objections to that.

First, "internal" often means dozens of developers, Jupyter notebooks, and agents can send requests. It only takes one of those machines being compromised — and the malicious VS Code extension that compromised 3,800 internal repos at GitHub in 2026 shows how fast a developer machine can become the entry point — for the attacker to inherit access to your GPU and your host.

Second, multimodal models have become the norm, not the exception. Models that reason about images and videos, like the ones we discussed with Elorian Glimpse, make the image processing pipeline mandatory. The more inputs your model accepts, the larger your attack surface grows. Image processing is no longer an option you can disable to make your life easier.

The fix: vLLM 0.32.0. As defense in depth, also update Ghostscript to 10.03.1 or newer (versions below 10.03.1 remain vulnerable to the sandbox escape) and Pillow to 12.3.0+, which now rejects the looping EPS sample used as the proof of concept.

CVE-2026-1159: one token ID and the whole engine goes down (CVSS 6.5)

Direct answer: yes, a single malformed token ID can crash your entire inference engine, all in-flight requests included. No code execution here, but a denial of service that is trivial to trigger and hard to diagnose.

The flaw, tracked under GHSA-q97c-p368-75c4, is an off-by-one error in vllm/tokenizers/hf.py. The validation code accepts a pre-tokenized token ID equal to the vocabulary size — even though valid IDs range from 0 to vocab_size - 1. This invalid token isn't masked before it reaches F.embedding, and in a tensor-parallel size 1 configuration with a vocabulary that is a multiple of 64 (the case for most mainstream models), the embedding layer raises a CUDA device-side assert.

Concretely, a CUDA assert doesn't merely reject a request: it corrupts the state of the CUDA context. The entire engine crashes. On a server handling hundreds of concurrent requests, a single user — whether intentionally or through a client-side bug — can take down the entire queue.

What makes this CVE particularly instructive is its banality. A >= comparison instead of > in an input validation, and there you have a denial-of-service vector against the most expensive infrastructure in your stack. The CVSS of 6.5 reflects this reality: no compromise, but availability that can be destroyed at will. Fixed in 0.32.0.

CVE-2026-115917 : CORS wildcard, or how your users' browsers consume your GPU (CVSS 3.4)

Direct answer: yes, any web page visited by one of your employees can call your unauthenticated vLLM server from their browser — list your models and send requests to your GPU. The CVSS of 3.4 is low, but don't be fooled: this is the easiest CVE in the batch to exploit.

vLLM's OpenAI-compatible server has a permissive default behavior: allowed_origins = * in CORS, and no authentication unless you explicitly configure --api-key or the VLLM_API_KEY environment variable. The consequence, documented in the OpenCVE advisory, is that a malicious web page — a phishing site, an ad, a booby-trapped article — can send GET /v1/models and POST /v1/chat/completions requests to your internal server from the browser of an employee who visits that page.

The browser sends the request, vLLM responds with the wildcard CORS headers, the browser accepts the response. The attacker doesn't see the content, but they trigger the execution. On an inference endpoint, this means: enumeration of your deployed models (sensitive information in itself) and consumption of your GPU capacity without your knowledge. At the scale of a team, a few open tabs are enough to degrade your production latency.

In our view, the CVSS of 3.4 underestimates the real impact in an enterprise, because it doesn't model the "internal server + LAN browsers" scenario well. The fix ships in 0.32.0, but the real lesson is broader: an inference server without authentication is not an internal server, it's a server open to anything that can reach the network — including browsers. Configure --api-key systematically, and add a reverse proxy with authentication if the endpoint is shared.

The rest of the batch: forged SHM, pickle.loads, and five medium advisories

Direct answer: the October batch includes two High advisories, five medium, and one low — and the second High deserves nearly as much attention as the first.

According to the analysis by Agentbeam, here is the breakdown:

CVE-2026-115912 deserves a word. Deserialization via pickle.loads is a classic Python vulnerability: pickle is not a data format, it's an execution format. A forged shared memory handle that reaches a pickle.loads is a direct path to arbitrary code execution. The CVSS of 7.5 is consistent — exploitation probably requires local access or a multi-tenant scenario, but in a deployment that shares a machine across multiple teams, that's not an exotic assumption.

The five medium advisories cover denial-of-service and gate bypass issues (vLLM's restriction mechanisms, such as token limits or input filters). Individually, each one seems minor. Taken together, they paint a picture: vLLM's input validation layer was deeply reworked between 0.30 and 0.32, and staying on an older version means stacking up attack vectors.

Update Checklist for a Self-Hosted Installation

Direct answer: version 0.32.0 covers the entire October batch, and 0.31.0 covers the previous wave. If you're on 0.30.x or lower, you're behind on both. Here is the procedure we recommend, in order.

Step 1: Assess your current state

pip show vllm
gs --version
pip show pillow

Three checks to perform:

• vLLM: aim for at least 0.32.0. Any earlier version remains exposed to the October batch.
• Ghostscript: 10.03.1 or newer — below this version, the host is vulnerable to the sandbox escape (CVE-2024-29510).
• Pillow: 12.3.0 or newer, which rejects the looping EPS sample used as a proof of concept.

Run this diagnostic on the host and in every Docker image that ships vLLM. Both environments have their own versions of Ghostscript and Pillow.

Step 2: Update

pip install --upgrade "vllm>=0.32.0"
pip install --upgrade "pillow>=12.3.0"

# On the host (Debian/Ubuntu)
apt-get update && apt-get install --only-upgrade ghostscript

If you use an official image, start from an image rebuilt after October 28, 2026 — rebuilding on top of a Docker cache can preserve the old layers.

Step 3: Hardening, regardless of version

# Authentication everywhere — never optional
export VLLM_API_KEY="your-strong-key"

# If you serve a model with image inputs, check that
# the format allowlist is active in your configuration

Three non-negotiable rules:

1. An API key on every endpoint, even "internal" ones. CVE-2026-115917 exists precisely because the default is permissive.
2. Ghostscript ≥ 10.03.1 on every host that runs vLLM. Even with vLLM 0.32.0, a vulnerable Ghostscript is a ticking time bomb for any future image pipeline bug.
3. A reverse proxy with authentication and CORS restrictions in front of any endpoint shared across teams.

Step 4: If you're on 0.30.x

You're stacked up with two waves of advisories. The September–October wave (RCE via code_revision, hang via min_tokens, cross-tenant crash via logprobs) was fixed in 0.31.0; the October 20 batch in 0.32.0. Don't do an incremental upgrade: jump straight to 0.32.0, test in a staging environment — an inexpensive lab VPS like the ones offered by Hostinger works perfectly fine for validating the version upgrade — then switch over.

Step 5: Set up ongoing monitoring

The vLLM project now publishes its advisories on its GitHub security page. Subscribe to releases and advisories, or plug a scanner like Trivy into your images. With 10 advisories published between September 23 and October 20, 2026, waiting for the next wave of press coverage before reacting is no longer a viable strategy.

What this batch reveals about self-hosted inference security

Direct answer: inference servers have become complex web applications, but their security hasn't kept up — and self-hosting makes you responsible for closing that gap.

Three lessons emerge from this October 2026 batch.

First lesson: multimodal processing is the new primary attack surface. The most serious CVE doesn't come through text, but through an image. It's a pattern that repeats across the ecosystem: as soon as a server accepts binary files from users, it inherits every vulnerability of every decoder in the chain. vLLM is merely exposing the flaws of Pillow and Ghostscript — but containing exactly this kind of propagation is precisely an inference server's job.

Second lesson: permissive defaults are the real enemy. CORS wildcard, no authentication by default, format detection without an allowlist — three of the vulnerabilities in this batch stem from "convenient to get started" design choices. Frameworks optimize for fast onboarding, and security becomes an opt-in that many forget to enable. In 2026, deploying an inference server without an API key should be as unthinkable as deploying an SSH server with a root password.

Third lesson: the patch cadence demands version hygiene. Two waves of advisories in less than a month, eight CVEs at once, 12 pages of accumulated advisories. AI inference projects are evolving at the speed of web frameworks, with the security maturity of a young project. If your update process is quarterly, you'll always be living two waves of vulnerabilities behind. The right approach for teams self-hosting models — and our guide to the best LLMs for coding stresses this point when comparing deployment options — is to treat the inference engine as a critical dependency: monthly patching at minimum, advisory monitoring, and a tested rollback.

One last opinion: the no-code temptation is real when it comes to democratizing internal access to these models, and our selection of the best no-code tools for using AI is testament to that. But every layer added in front of an inference endpoint is a layer that must be configured with the same rigor. A no-code tool connected to an unauthenticated vLLM is simply a new path to CVE-2026-115917.

❌ Common Mistakes

Mistake 1: "My server isn't exposed to the internet, so this doesn't concern me"

This is the most common mistake, and the most costly one. CVE-2026-115917 specifically exploits internal servers via LAN browsers. CVE-2026-115915 only requires access to the API — which, in a company, often means dozens of people and workstations. An internal endpoint without authentication is a public endpoint with one extra step.

Mistake 2: Updating vLLM without updating Ghostscript

The vLLM 0.32.0 patch prevents EPS bytes from reaching Ghostscript via the image pipeline. But if your host keeps a Ghostscript vulnerable to CVE-2024-29510, any future pipeline vulnerability — and there will be others — reactivates the code execution path. Update both, systematically.

Mistake 3: Rebuilding the Docker image on top of the old one

docker build with an existing cache can keep layers containing the old Ghostscript or the old vLLM. After a security update, start fresh with docker build --no-cache or a rebuilt base image, then verify the versions inside the container, not just on the host.

Mistake 4: Confusing "no RCE" with "not serious"

CVE-2026-115916 (engine crash) and the medium DoS advisories don't allow code execution, and their CVSS reflects that. But on a GPU infrastructure that costs thousands of euros per month, a denial of service triggerable by a single request is a major incident. Availability is part of security.

❓ FAQ

Should I really upgrade to 0.32.0 if I'm already on 0.31.0?

Yes. Version 0.31.0 fixes the previous wave (RCE via code_revision, hang via min_tokens, cross-tenant crash via logprobs), but not the October 20, 2026 batch. The eight October advisories — including the two High ones (EPS/Ghostscript and SHM/pickle) — are only fixed in 0.32.0.

Is the vLLM patch enough to neutralize the Ghostscript issue?

It neutralizes the known exploitation path by preventing EPS bytes from reaching Ghostscript through the image pipeline. But defense in depth remains necessary: Ghostscript ≥ 10.03.1 on the host and Pillow ≥ 12.3.0 close the upstream and downstream layers in case a new variant appears.

How can I quickly check whether my installation is vulnerable?

Three commands: pip show vllm (vulnerable if < 0.32.0), gs --version on the host and in the container (vulnerable if < 10.03.1), and verify that --api-key or VLLM_API_KEY is properly configured on your server. The whole thing takes less than five minutes.

Is wildcard CORS really exploitable if my server has no authentication?

Yes, and it's actually the worst-case scenario. Any web page visited from a browser on the LAN can call GET /v1/models and POST /v1/chat/completions on your server. With an API key configured, the attack is blocked absent a key leak — which makes it one more argument for systematic authentication.

Do these vulnerabilities also affect managed APIs (OpenAI, Anthropic, etc.)?

No. These CVEs concern the open source vLLM engine in self-hosted deployments. Managed providers manage their own infrastructure and their own patches. That said, the pattern "user input → third-party decoder → RCE" is a generic risk: what changes is who bears responsibility for patching.

✅ Conclusion

Eight CVEs in a single publication, two code execution paths, an engine crash from a single request, and CORS left open by default: vLLM's October 2026 batch marks a turning point in the maturity — and the demands — of self-hosted inference security. Upgrade to 0.32.0 this week, update Ghostscript and Pillow, and add an API key to every endpoint. If you're evaluating which models to deploy on this freshly patched infrastructure, our roundup of the best AI tools for coding will help you pick the stack that fits your team.