vLLM: unrestricted image decoder selection turns an uploaded image into host command execution

CVSS 8.1CVE-2026-115915AI/ML frameworks & servingcurated

Impact

Any request path that accepts an image hands attacker-controlled bytes to Pillow without constraining which decoder runs, and the declared MIME type does not limit the chosen format. An EPS payload therefore reaches Ghostscript: on a host whose Ghostscript is affected by CVE-2024-29510, the attacker executes commands as the vLLM process, which on a GPU serving node normally means access to the model weights, the served API credentials and whatever the pod's service account can reach. With Pillow 12.0.0 through 12.2.0 the same path instead triggers CVE-2026-59203 and exhausts the media-loading workers, taking the endpoint down. Hosts without either vulnerable dependency are not exposed to the corresponding impact. Fixed in vLLM 0.32.0.

Who can reach it

Anyone who can send a multimodal request to the vLLM OpenAI-compatible endpoint; no authentication is needed beyond whatever fronts the endpoint, and no GPU access is required.

What to do

Upgrade vLLM to 0.32.0 and restart the serving processes - a rolling restart of the model replicas, no node drain or reboot. If an immediate upgrade is not possible, remove Ghostscript from the serving image and move off Pillow 12.0.0-12.2.0, or disable image input on the affected endpoints.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-115915 https://github.com/vllm-project/vllm/security/advisories/GHSA-h3rc-j82p-2c3h https://github.com/vllm-project/vllm/commit/710ac56e691d4713feca50a43e6c440f07d373fd https://github.com/vllm-project/vllm/releases/tag/v0.32.0

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.