vLLM project vLLM at a glance
Between October 23 and 28, 2026, vLLM published advisories for three high-severity code-execution bugs and several crash bugs, most reachable through multimodal API requests. Fixes shipped in vLLM 0.31.0 and 0.32.0; anyone self-hosting models with vLLM should run 0.32.0 or later.
vLLM project vLLM: status
- Affected
- vLLM 0.7.3 through 0.30.x: code_revision code execution (CVE-2026-114053, requires --trust-remote-code) and mm_processor_kwargs memory exhaustion (CVE-2026-114055); fixed in 0.31.0
- vLLM before 0.32.0: shared-memory handle forgery to pickle deserialization when --mm-processor-cache-type shm is set (CVE-2026-115912), and EPS images reaching a vulnerable host Ghostscript (CVE-2026-115915); fixed in 0.32.0
- CVE identifiers
- Status as of
- Discovered by
- Independent researchers credited on the vLLM GitHub advisories
What changed with vLLM project vLLM
From October 23 to October 28, 2026, the vLLM project published a batch of GitHub security advisories for its open-source model server. The fixes were already in releases 0.31.0 (October 5) and 0.32.0 (October 18), so the advisories mainly tell operators which older versions are exposed. Three issues are rated high severity because they can lead to code execution, and several more let a single request crash the engine.
CVE-2026-114053 (CVSS 8.1) lets an API client set mm_processor_kwargs.code_revision and make vLLM import processor code from a different revision of the served model's repository. It only applies when the operator enabled --trust-remote-code, the model uses dynamic processor code, and the attacker can create a revision, such as a community pull-request ref on Hugging Face. The advisory notes that the /tokenize route is not covered by vLLM's API-key middleware. vLLM 0.31.0 rejects per-request mm_processor_kwargs by default, which also fixes CVE-2026-114055, a related out-of-memory crash.
CVE-2026-115912 (CVSS 7.5) affects servers started with --mm-processor-cache-type shm: an authenticated caller could forge a shared-memory handle and reach Python pickle deserialization in a worker, even with insecure serialization turned off. CVE-2026-115915 (CVSS 8.1) let image bytes labeled as PNG be parsed as EPS, which reaches the host's Ghostscript; on hosts with a vulnerable Ghostscript build, that can mean command execution. Both are fixed in 0.32.0, along with medium-severity denial-of-service bugs and a permissive default CORS setting.
How to fix it: vLLM project vLLM
1. Update
Upgrade vllm to 0.32.0 or later, which includes the 0.31.0 fixes, then rebuild and redeploy every container image and worker that serves models.
github.com (opens in a new tab)2. Configuration
Leave --trust-remote-code off unless you have reviewed the model's code, and do not opt back in to per-request mm_processor_kwargs for clients you do not trust.
github.com (opens in a new tab)3. Workaround
If you cannot upgrade yet, put the server behind an authenticating reverse proxy that also covers /tokenize, avoid --mm-processor-cache-type shm, and update or remove Ghostscript on hosts that accept images.
github.com (opens in a new tab)
Instruction for your AI agent
Search requirements files, lockfiles, Dockerfiles and deployment manifests for vllm. If any pin or image uses a version below 0.32.0, propose upgrading to 0.32.0 or later and rebuilding the image. Flag any launch command that uses --trust-remote-code or --mm-processor-cache-type shm, or that exposes the vLLM port publicly without an authenticating proxy, and ask the user before changing deployment settings.
Based on the official guidance linked below. Review it before giving it to an agent that can change your systems.
Advisories
Where to compare vLLM project vLLM
Independent leaderboards and official resources for comparing this model yourself. Rankings change often; each site shows its own current data.
Why vLLM project vLLM matters for businesses
If you self-host open models for clients, vLLM is often the engine behind an OpenAI-compatible endpoint. Pin vllm 0.32.0 or later, rebuild the container images, keep the server behind your own authentication instead of exposing it directly, and leave trust-remote-code off unless you have reviewed the model's code. Managed APIs are not affected by these bugs; only infrastructure you run yourself is.
Sources for this story
- vLLM: Request-controlled mm_processor_kwargs.code_revision allows remote code execution (opens in a new tab)Official
vLLM project on GitHub · github.com
- vLLM: Public multimodal SHM handle forgery reaches worker-side pickle.loads() (opens in a new tab)Official
vLLM project on GitHub · github.com
- vLLM: Untrusted EPS inputs can trigger denial of service or Ghostscript RCE (opens in a new tab)Official
vLLM project on GitHub · github.com
- vLLM: DoS via unvalidated mm_processor_kwargs in multimodal image processors (opens in a new tab)Official
vLLM project on GitHub · github.com
- vLLM v0.32.0 release (opens in a new tab)Official
vLLM project on GitHub · github.com
- CVE-2026-114053 (opens in a new tab)Official
NIST National Vulnerability Database · nvd.nist.gov
Last verified: . IA Compa summarizes public announcements for business readers. We are not affiliated with the companies mentioned. Always confirm details, pricing, and availability with the official source.
- #security
- #cve
- #vllm
- #model-serving
- #multimodal
- #self-hosting