vLLM lets an EPS image disguised as PNG reach Ghostscript and run code

October 20, 2026. The vLLM project publishes advisory GHSA-h3rc-j82p-2c3h, documenting CVE-2026-115915: a code-execution path that runs through an image. October 18, 2026. Release 0.32.0 had already closed the flaw by limiting untrusted images to raster formats. May 2, 2024. Ghostscript fixed CVE-2024-29510, the format-string bug that CVE-2026-115915 re-arms. The point that matters: an inference server that accepts images turns its image decoder — and everything it calls — into remote attack surface.

A model server becomes an image reader

vLLM is the most widely self-hosted LLM serving engine, sitting behind the OpenAI-compatible API of countless GPU clusters. Multimodal models — the ones that read an image attached to a request — force the server to decode that image before handing it to the model. That is exactly where the flaw lives.

In vLLM 0.30.0, the ImageMediaIO component passed attacker-controlled bytes to Pillow’s format autodetection without restricting the accepted formats. The request’s MIME label — image/png, say — did not constrain which decoder actually ran. An EPS file labeled image/png therefore sailed past the label and landed in Pillow’s EPS handler, which calls the host’s Ghostscript binary.

Code execution requires a second, older bug. On a host whose Ghostscript is affected by CVE-2024-29510 — a format-string flaw present from Ghostscript 9.50 through 10.03.0 that bypasses the -dSAFER sandbox — the EPS file can run commands with the vLLM process’s privileges. The advisory author reproduced command execution at the loader level using the PyPI wheel vllm==0.30.0, Pillow 12.3.0, and Debian’s Ghostscript 10.03.0.

Ghostscript is not installed by vLLM — but your base image may carry it

That is precisely the trap: vLLM’s dependencies do not declare Ghostscript, so the project never installs the offending binary. But a CUDA image built on a general-purpose distro, or one someone extended with document tooling — a PDF-ingest sidecar, for instance — carries it without anyone having asked for it. The flaw fires only when two conditions coincide: a multimodal model is exposed, and a vulnerable Ghostscript is present in the container.

That mismatch is what makes CVE-2026-115915 insidious. A vulnerability scanner sees nothing in pip list — Ghostscript is not there. You have to inspect the image itself. The same advisory also describes a standalone 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 saturated every media-loading thread and blocked a legitimate request.

The fix: restrict to raster formats

Release 0.32.0, published on October 18, fixes the problem at the root. The release note sums up the change in one line: “untrusted images are limited to raster formats.” The EPS path is closed, and the list of accepted formats no longer depends on trusting the MIME label.

Two details complicate the upgrade. First, vLLM 0.30.0 did not pin Pillow: upgrading vLLM alone can leave a vulnerable Pillow in place. You need Pillow 12.3.0 or later, which closes the CVE-2026-59203 loop. Second, the container image matters as much as the version number: rebuilding the image without Ghostscript — or with 10.03.1 or later — removes the second stage, even if a future regression reopens the first.

CVE-2026-115915 is not the first signal from this ecosystem. This blog covered the LMCache pickle-deserialization RCE on vLLM servers, and the Pillow filename-triggered flaw. The cross-cutting lesson is the same: an inference engine’s boundary does not stop at prompts — it includes every third-party decoder that processes user-controlled bytes.

Verdict

If you expose a vLLM server with a multimodal model, move to 0.32.0 this week and rebuild the container image without a vulnerable Ghostscript: that is the only fix that covers both stages of the chain. If you do not know whether your base images carry Ghostscript, run dpkg -l ghostscript or rpm -q ghostscript inside the inference container — the absence of a declared dependency proves nothing. And if you serve third-party clients, treat the attached image as untrusted exactly like the prompt: restrict accepted formats at the gateway, never trust the MIME header, and watch vLLM’s advisories, of which it published ten between September 23 and October 20. The image flaw is a symptom of a badly drawn trust boundary — fixing it means redrawing that boundary.

References

• GitHub — vLLM Security Advisory GHSA-h3rc-j82p-2c3h (CVE-2026-115915)
• GitLab Advisories — vLLM: CVE-2026-115915
• NVD — CVE-2026-115915
• Codean Labs — CVE-2024-29510: Ghostscript format string exploitation
• vLLM — Release notes 0.32.0
• Beri.net — vLLM 0.30.0 Can Run Code Through Ghostscript Images (October 26, 2026)
• ETTAYEB — Pillow 13.0 fixes command execution triggered by a filename
• ETTAYEB — LMCache exposes an unpatched critical RCE via a single ZeroMQ message on vLLM servers