CVE-2026-114053 and four more: vLLM before 0.31.0 lets a request pick which processor code runs and lets anonymous clients crash or hang the server, upgrade to 0.31.0

What it is

CVE-2026-114053 (GHSA-h3rc-6mm3-gc2m, vLLM 0.7.3 to before 0.31.0): a multimodal request can set mm_processor_kwargs.code_revision, which is passed to AutoProcessor.from_pretrained. When the served model's processor uses dynamic auto_map code and the operator enabled trust_remote_code, the client chooses which revision's Python gets imported. An attacker who controls a revision in the served model repository (for example a community pull-request ref) can run code through the unauthenticated /tokenize endpoint.

CVE-2026-114050 (GHSA-p92p-rxj5-7p2x, before 0.31.0): the user-supplied uuid on multimodal content parts is used verbatim as the cache key, and the API-side and engine-side caches evict independently with no consistency check. A sequence of requests from one unauthenticated client makes the engine substitute stale image data and crash the whole serving instance.

CVE-2026-114051 (GHSA-4xqp-c3mv-qff7, before 0.31.0): a request to /inference/v1/generate with max_tokens set to null and a huge min_tokens skips validation in the API process, then kills the EngineCore input thread. The process stays up and /health returns 200, but every later request hangs until a manual restart.

CVE-2026-114052 (GHSA-823j-m4cj-hmjf, after 0.24.0 and before 0.31.0): when serving a MOSS-Audio model, every distinct mm_processor_kwargs value sent to /tokenize creates and caches a new processor in an unbounded dictionary. /tokenize sits outside the --api-key protected routes, so anyone who can reach it can exhaust host memory.

CVE-2026-114055 (GHSA-gx7p-2j49-hfq4, from 0.7.3): per-request mm_processor_kwargs such as image size, patch, crop or frame counts reach multimodal processors (Isaac, InternVL, H2OVL and others), so one request can force an out-of-memory crash of a shared server.

How to check

1. Check your vLLM version; 0.7.3 up to anything before 0.31.0 is affected by at least one of these.
2. Check whether you start vllm serve with --trust-remote-code and serve a model whose processor uses auto_map code, which is the setup the code-execution bug needs.
3. Check whether /tokenize and /inference/v1/generate are reachable by people you don't trust; --api-key does not protect /tokenize.

How to fix

1. Upgrade vLLM to 0.31.0 or later.
2. Until you can upgrade, don't expose the vLLM HTTP server directly; put it behind your own authenticated proxy and block /tokenize and /inference/v1/generate from untrusted clients.
3. Only use --trust-remote-code with model repositories you control, and pin the model revision.

pip show vllm | grep -i version
pip install -U 'vllm>=0.31.0'

Sources

• GitHub advisory GHSA-h3rc-6mm3-gc2m: request-controlled code_revision allows remote code execution ↗
• GitHub advisory GHSA-p92p-rxj5-7p2x: forged multimodal UUID crashes the engine ↗
• GitHub advisory GHSA-4xqp-c3mv-qff7: oversized min_tokens hangs the engine ↗
• GitHub advisory GHSA-823j-m4cj-hmjf: MOSS-Audio processor cache memory exhaustion ↗
• GitHub advisory GHSA-gx7p-2j49-hfq4: DoS via unvalidated mm_processor_kwargs ↗
• vLLM v0.31.0 release ↗
• NVD: CVE-2026-114053 ↗