vLLM publishes 18 security advisories in four days, including a remote code execution bug

What did vLLM disclose between 6 and 9 October?

vLLM is one of the most widely used open-source inference servers: software that loads a model onto GPUs and answers requests through an OpenAI-compatible API. Companies run it on their own hardware when they choose self-hosting, so its security is their security.

On 6 October 2026 the project published seven security advisories on its GitHub repository, and on 9 October another eleven. The project rates eight of the 18 as high severity, nine as medium and one as low. Together the advisories credit 18 different GitHub accounts as reporters, coordinators or fix developers. When we checked on 12 October, none of the 18 had a CVE identifier yet, which matters because many vulnerability scanners match on CVE IDs and may not flag them.

The burst is part of a longer pattern. The same advisory page lists 37 vLLM advisories published since 1 September 2026, most of them denial-of-service or resource-exhaustion bugs in the request path. For teams deciding between self-hosting a model rather than using a managed API, that steady flow is part of the operating cost.

Which of the vLLM flaws matter most?

The headline issue is the remote-code-execution advisory, rated high with a CVSS score of 8.1. A client could set mm_processor_kwargs.code_revision in a multimodal request, and on a server running with --trust-remote-code that value reached the Transformers library's AutoProcessor and chose which revision of the model repository's Python processor code was imported. The reporter notes that an attacker would need to control a revision of the served repository, for example a community pull-request branch on the Hugging Face Hub, and that the default trust_remote_code=False setting is not affected. It is the same class of risk as ProjectDiscovery's backdoored-model demonstration: model repositories can carry code, and code that loads automatically is an attack surface.

Two details raise the stakes. The vulnerable path can be reached through /tokenize, which vLLM's own security guide lists among the endpoints that need no API key, so setting --api-key alone does not protect it. And the advisory says the affected version range was not bisected, so operators should not assume old releases are safe.

Other high-rated advisories are less dramatic but more likely to bite. One describes a server-side request forgery through the X-Request-Id header that could make a prefill worker using the now-removed P2pNcclConnector connect to an attacker's host and send it the KV cache of a request, which contains the prompt. Another shows a single request with prompt logprobs crashing the shared engine process, and every co-tenant's in-flight work with it, on deployments that use KV-cache connectors such as LMCache or NIXL. A medium-rated report shows an oversized min_tokens value stopping a server from serving anything while its /health endpoint keeps answering 200, so orchestration never restarts it.

What changed in vLLM 0.31.0?

vLLM 0.31.0 shipped on 5 October, the day before the first batch of advisories, with 717 commits from 307 contributors. Its release notes give security its own section. Per-request mm_processor_kwargs and media_io_kwargs are now rejected unless the server starts with a new --trust-request-mm-kwargs flag; prefix-cache block hashes tag each extra key by its source and include the LoRA path, so a LoRA name and a cache_salt can no longer collide; fresh multimodal payloads take precedence over a stale receiver cache; and a min_tokens value above the filled-in max_tokens is rejected instead of wedging the engine.

The first change is also listed as breaking. Applications that tune image, video or audio preprocessing on each request will get errors after upgrading until the operator either moves those settings to server-level --mm-processor-kwargs and --media-io-kwargs or enables per-request overrides. vLLM's security guide says to enable that only when every API client is trusted. Several of the other advisories were fixed in releases going back to 0.18.0 in March and 0.24.0 in June, and were simply disclosed now.

What should teams running vLLM do now?

The advisories and the security guide point to the same short list. None of it requires new tools, and most of it is configuration:

1. Upgrade to vLLM 0.31.0 or later. It is the first release that contains every fix listed in the 18 advisories.
2. Do not run --trust-remote-code on servers that untrusted clients can reach, and pin both the model revision and any custom processor code you have reviewed.
3. Put vLLM behind a reverse proxy that allowlists only the endpoints you need. The guide notes that /tokenize, /detokenize, /health and several utility routes are not gated by --api-key.
4. Leave --trust-request-mm-kwargs off unless every client is trusted, and set per-tenant cache_salt values on shared servers.
5. Monitor real request throughput, not just /health, so a wedged engine that still reports healthy is caught and restarted.

Why do inference servers keep collecting security bugs?

Most of the 18 bugs share a shape: a request field that the server trusted more than it should. Multimodal inputs, speculative decoding, disaggregated prefill and decode, and shared KV caches all add code paths where one client's values reach a process that serves everyone. vLLM's engine core is a single scheduler, so an unhandled exception or an endless loop there is a denial of service for every user of that server, not just the attacker.

How the bugs were found is also changing. One advisory says its initial discovery was made by AI scanning tools in Microsoft Security FORGE Labs and that human experts then validated the claims. That matches the wider trend we covered with Anthropic's OSS Scanner and its disclosure dashboard of 6,157 reported bugs: automated tools are surfacing more real bugs in open-source AI infrastructure, which puts pressure on maintainers to triage and patch faster.

What do the advisories not tell you?

Severity ratings here are the project's own, assigned through GitHub's advisory form, and the CVSS scores vary in completeness: some advisories carry a full vector, others only a label. Without CVE IDs, the October advisories may not appear in tools that rely on the National Vulnerability Database until identifiers are assigned.

None of the advisories we reviewed reports exploitation in the wild. Several depend on optional features, such as the P2pNcclConnector, specific multimodal processors or KV connectors, so the real exposure of a given deployment depends on how it is configured. We did not reproduce any of the issues; this article is based on the advisory texts, the 0.31.0 release notes and vLLM's security guide as published on GitHub and docs.vllm.ai.