vLLM security advisories 2026: which version fixes them, by how your endpoint is exposed

Which vLLM version to run in October 2026

As of 24 October 2026, run vLLM 0.32.0 of 18 October 2026, or at least 0.31.0 of 5 October 2026. Of the advisories vLLM published in its GitHub repository between August and early October 2026, 0.31.0 is the first release outside the affected range of every one whose page we could open, and 0.32.0 adds further hardening. An endpoint that only trusted internal applications reach is less exposed than one open to all staff, but most of these flaws need nothing more than an ordinary request, so the version matters in both cases.

This page lists the advisories by the way a vLLM server is reached, because that decides which ones apply to you. The list was read on 24 October 2026. vLLM aims at a release about every two weeks, and new advisories appear between releases, so check the list again before every upgrade and treat this page as a dated snapshot.

vLLM repository security advisories and GitHub advisory database entries, opened one by one on 24 October 2026; dates of 0.30.0 to 0.32.0 from vLLM's GitHub release pages. The tables below list each advisory with its condition.

For the last three months the repository list shows at least 17 advisories published between 11 August and 6 October, three of them High, twelve Moderate and two Low. The list on GitHub is not sorted by publication date, so we opened each entry. vLLM's security policy defines Critical as "CVSS ≥ 9.0" and High as "between 7.0 and 8.9", and handles the two differently: Critical and High fixes are prepared in a private fork coordinated in advance with parties on a prenotification list, while Moderate and Low fixes go out as public pull requests without embargo.

Exposure 1: anyone who can send API requests

These advisories need only network access to the API port, and several work without an API key. On a server whose port the whole company network reaches, every one of them applies.

advisory pages on GitHub (GHSA-2phq via GitHub's advisory database), read 24 October 2026; GHSA-v5gm from CVE-2026-100654 as mirrored in GitHub's advisory database ("vLLM before 0.29.0"). Scores are CVSS 3.1 as shown on GitHub, except the CVE record (CVSS 4.0, 7.1).

The first row shows the pattern. GHSA-25q3-v2hm-8vpf, published on 3 September 2026, describes a request to /v1/embeddings or /pooling with a negative token id that kills the engine "via a CUDA device-side assertion"; no authentication is needed, the server stays down until restarted, and the advisory says process supervision is not a workaround because the request can be repeated at once. For servers that cannot be upgraded, it suggests rejecting negative integers in input at a gateway and restricting access to those routes. The cache_salt advisory, published on 12 September, works on the chat, completions, responses and pooling endpoints and on the Anthropic-style /v1/messages, without a key, because prefix caching is on by default and no request-body limit applies by default.

The API key itself is the subject of the oldest entry in the table. GHSA-94f4-hr76-p5j6 (CVE-2026-48746), published on 2 June 2026 and rated Critical, let an attacker use the OpenAI-compatible API without the configured key in versions from 0.3.0 to before 0.22.0; servers behind "an RFC-conforming web server such as nginx" were not affected. Even on a current release the key does not cover every route. vLLM's security guide, dated 19 October 2026, says the key applies "only for endpoints under the /v1, /v2, /inference, and /cohere path prefixes" and names /invocations, /pooling, /classify, /score, /rerank, /pause, /update_weights and /metrics among the routes outside them. Two of the 2026 advisories add /tokenize, which the authentication check does not cover either. Our guide to securing a GPU server describes the reverse proxy and firewall that close these routes.

Exposure 2: images, audio and video in requests

Multimodal models accept media in requests, and media decoding is where many of the 2026 advisories sit. They are denial of service through memory, CPU or GPU decoder use; none of those we read allows code execution.

advisory pages on GitHub (GHSA-ph3r via GitHub's advisory database, published to the repository on 28 September 2026), read 24 October 2026. GHSA-x6mc appears in the repository list, published 23 September 2026; its page did not load, and vLLM 0.30.0's notes list "Request-controlled video sampling capped for GLMGA (#54935) and Qwen-VL (#56729) backends".

Version 0.31.0 changed the default behind several of these. Its release notes say "per-request mm_processor_kwargs and media_io_kwargs are rejected unless --trust-request-mm-kwargs is set", and vLLM's security guide adds that only deployments whose API clients are trusted should start the server with that flag. The guide also recommends --allowed-media-domains against server-side request forgery, VLLM_MEDIA_URL_ALLOW_REDIRECTS=0 so that redirects cannot get around the list, and size limits such as VLLM_MAX_MEDIA_DOWNLOAD_SIZE_MB, 256 by default. Release 0.32.0 opens untrusted images with "a raster-format allowlist", which denies EPS, PostScript and WMF. If your model takes only text, none of this applies; if it takes images or video from users, these settings belong in the deployment with any version.

We supply GPU servers for private LLMs with the operating system, driver and container runtime installed on request; tell us which vLLM release and models you run and how users reach them, and our team replies with the upgrade path and the configuration for the next server.

Exposure 3: model code and pinned revisions

The third set concerns what a server loads rather than what users send. Two of the three High-rated repository advisories of August to October are here.

advisory pages on GitHub, read 24 October 2026; GHSA-hhv2 from CVE-2026-100653 as mirrored in GitHub's advisory database ("Versions 0.22.1 through 0.28.0", fixed in 0.28.0, CVSS 4.0 8.3).

GHSA-h3rc-6mm3-gc2m, published on 6 October 2026, is the reason for the 0.31.0 minimum. With --trust-remote-code on, a model whose processor uses dynamic code and a multimodal request, a client could set mm_processor_kwargs.code_revision and make the server load processor code from a revision an attacker controls, such as a pull request on the model's repository, which the advisory calls arbitrary Python execution in the API process by "an unauthenticated network client". Versions from 0.7.3 to before 0.31.0 are affected; the default, with remote code off, is not. GHSA-3c86-2m5g-59q7, published on 28 August, is different: the LlavaOnevision2 processor loader ran the model's code even with trust_remote_code=False, so a crafted model could execute code without the flag; it needs someone to load that model, and 0.28.0 fixed it.

The pin advisories are about integrity. A deployment started with --revision or --code-revision expects every file to come from that revision; GHSA-3ww4-5jv9-j5gm, published on 10 June 2026, found loaders that fetched secondary files, such as processors, GGUF files or side weights, from the default branch instead, and a later CVE record found two more architectures. Keep remote code off unless a model needs it, pin revisions, and serve models from a local model store that you fill through one controlled path, as our guide on installing an LLM server without internet access describes.

Exposure 4: internal ports, scale-out and disaggregated serving

A server that splits a model across nodes, or separates prefill and decode, opens ports beyond the API. vLLM's security guide states that "All communications between nodes in a multi-node vLLM deployment are insecure by default", names PyTorch Distributed, KV cache transfer and parallel communication, gives 14579 as the default KV transfer port and 29500 for the data-parallel master, and advises blocking every incoming connection except the API port.

advisory pages in GitHub's advisory database (published to the repository on 23 September 2026), read 24 October 2026; the two CVE records describe "vLLM through 0.29.0", published by NVD on 21 September 2026, and name no fixed release (they link pull requests 54807 and 49796).

Release 0.30.0 also moved the scale-out endpoints behind a switch: its notes say /render, /derender and /inference/v1/generate "are no longer registered on plain vllm serve" and are opt-in through --enable-scale-out. For the NIXL and Mooncake records, check the linked pull requests against your release before you run a disaggregated deployment for untrusted users. A single server that runs each model on one card or one tensor-parallel pair opens none of these ports to the network if the firewall admits only the API port. Our guide to disaggregated LLM serving with NVIDIA Dynamo describes when a prefill and decode split is worth the extra surface.

What 0.31.0 and 0.32.0 change besides fixes

An upgrade for security brings the other changes of the release with it. In 0.31.0, the breaking changes include the rejection of per-request multimodal kwargs described above, the removal of tokenizer_mode="slow" and a renamed Mamba prefix-cache flag. Release 0.32.0 lists "Default CORS settings no longer allow every origin in the Python and Rust frontends", so a browser front end that called vLLM directly needs its origin configured; it drops Python 3.10, with 3.11 as the minimum; it requires transformers from 5.16.1 to below 5.20.0; and it treats max_tokens "as an upper bound on output rather than reserved from the context window". It also bounds P2P ZMQ peer sessions through VLLM_P2P_MAX_PEERS, 128 by default, and returns 400 for structured-output JSON schemas nested more than 64 levels. The 0.32.0 notes name advisory identifiers next to some of these items, among them GHSA-q97c-p368-75c4 for an off-by-one in the tokenizer's max_token_id and GHSA-frvg-qw88-hww9 for ZMQ socket exhaustion through unique peer addresses. On 24 October 2026 neither page could be opened and neither appeared in GitHub's advisory database; if they are published with 0.31.0 in the affected range, 0.32.0 becomes the minimum, so check them before you settle on 0.31.0.

Model support pulls in the same direction on RTX PRO Blackwell cards. vLLM 0.32.0 runs the NVFP4 KV cache on SM12x, and 0.30.0 made native NVFP4 kernels the default on SM120, as our guide to SM120 software support explains. A server pinned to an older release for a model therefore gives up both. Our guide to operating a private LLM platform suggests an upgrade every second or third minor release and sooner for a security fix, with an evaluation run before each switch.

How to keep track after 24 October 2026

Advisories reach you through three channels, and they differ. The repository list on GitHub carries vLLM's own advisories with affected and patched ranges. GitHub's advisory database republishes them, adds CVE numbers and marks them reviewed, and the reviewed entries name the pip package vllm, so dependency scanners that read the database can flag an installed version. CVE records filed by other parties, through VulDB or VulnCheck, also appear there as unreviewed entries without a package: two published on 6 October 2026, CVE-2026-105922 in the penalty handler and CVE-2026-105775 in a Mamba layer, describe "vLLM up to 0.31.0", are rated Low at 2.1 and name no fix. Read those records against the linked issues rather than the version alone.

1. Record the exposure. Write down which routes users reach, whether --trust-remote-code is on, whether the model takes media and whether any internal port leaves the host.
2. Read new advisories against it. Most entries state their preconditions; an audio advisory does not concern a text-only server.
3. Upgrade on a second instance first. Read the release notes of every skipped version for breaking changes, run your evaluation set and the load test, then switch.

Our Private AI/ML service, delivered with our engineering partner Vixen.UNO, builds and supports private LLM platforms on vLLM; write to us with your current release and how the endpoint is exposed, and we tell you which advisories apply and what the upgrade involves.

FAQ