BuildNot yet confirmed elsewhere1 publisher2 min readPublished
OSV.dev returned 'not found' for five vLLM advisories that 0.31.0 fixes
vLLM published more than 30 security advisories on GitHub between 12 September and 9 October, most without a CVE ID, a dev.to author reports. The author's five OSV.dev lookups came back empty, so a clean scanner run says little about any server below 0.31.0.
The Engineer · Build desk
Timeline. 12 September 2026: vLLM starts publishing what becomes more than 30 GitHub security advisories. 5 October 2026: vLLM 0.31.0 is released, and the post says it fixes all of them. 9 October 2026: the advisory run ends. 11 October 2026: five advisory lookups on OSV.dev each return 'not found'.
| Date | Event | Claim |
|---|---|---|
| September 12, 2026 | vLLM starts a run of more than 30 GitHub security advisories | 1 |
| October 5, 2026 | vLLM 0.31.0 released; the post says it fixes all of the advisories | 19 |
| October 9, 2026 | Last of the more than 30 advisories published | 1 |
| October 11, 2026 | Five advisory lookups on OSV.dev each return 'not found' | 3 |
What happened
- The GitHub Advisory Database did not have those five advisories either, according to the same 11 October check.
- vLLM 0.31.0 shipped on 5 October 2026, and the post says it fixes every advisory in the set.
- Most of the advisories describe denial of service, and a vLLM server is usually shared, so one crashing request takes it down for every user and app behind it.
- GHSA-rhcx-5729-88vg, scored CVSS 7.7 and affecting 0.8.5 up to 0.31.0, lets a request with prompt_logprobs crash the server for every tenant.
- Two older advisories with CVE IDs, CVE-2026-48746 (before 0.22.0) and CVE-2026-22778 (0.8.3 up to 0.14.1), apply to pinned old versions.
Why it matters
- decision Operators on 0.30.0 or older have to check the running version by hand, through /version, pip show vllm or the Docker image tag. The post's checker lists 0.30.0 as still carrying two advisory groups.
- cost Upgrading to 0.31.0 breaks any client that sends mm_processor_kwargs on each request until those settings move to the server-level --mm-processor-kwargs flag.
- constraint The --api-key flag cannot be the only gate on a shared server. Per the advisory, /tokenize accepts the revision choice without authentication even with the key set, and the post recommends an authenticating reverse proxy.
- contradiction The post says 0.31.0 fixes everything, yet two listed ranges end 'up to 0.31.0'. The advisory pages have to settle whether that bound includes the release.
The post's test is five lookups. Against a set of more than 30 advisories, that covers at most one in six [17]. The claim that most of the set lacks a CVE ID is the author's count [2], and the post does not publish lookup results for the rest. The author concludes that scanners reading OSV.dev and the GitHub Advisory Database cannot report what those databases do not hold [18]. The author also says the same pattern showed up in Open WebUI, Flowise and RAGFlow: projects publish GitHub advisories without requesting CVE IDs, and the databases pick up only some of them, sometimes weeks later [20].
Exposure depends on configuration, and the post is specific about it. GHSA-h3rc-6mm3-gc2m, scored CVSS 8.1, applies only with trust_remote_code on and a multimodal model whose processor loads code from the model repository [6]. The default is off, and on the default the post says that advisory does not apply [6]. The KV-cache leak needs a disaggregated setup using P2pNcclConnector, where a crafted X-Request-Id header can make the server connect out [9]. KV-cache tensors hold other users' prompt data [9]. Other bugs depend on version alone. The out-of-range stop_token_ids bug covers 0.20.1 up to 0.29.0 and can crash the engine or write out of bounds on the GPU [10].
On the processor-kwargs change, we think rejecting per-request arguments by default is the right tradeoff for a shared server, where one request can exhaust CPU or GPU memory [7]. A closed deployment with trusted clients can opt back in with --trust-request-mm-kwargs [7].
The post's counting window runs four days past the 5 October release [21]. Anything published after its 11 October lookup sits outside the claim that 0.31.0 fixes all of them [c3, c6].
One disclosure. The post says it was written by an AI, MV2, made by Munim, Inc. [15]. The checker it recommends is hosted at munimv2.github.io [15]. For everyone else, its fallback is the project's own advisory page [16].
What to watch
- Whether OSV.dev and the GitHub Advisory Database ingest the five GHSA entries, since the author's check is a snapshot from 11 October.
- Any vLLM advisory published after 9 October that 0.31.0 does not cover.
- Whether the advisories without CVE IDs are later assigned them, which is what scanners key on.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence40
- Adoption
- Insufficient
- Hype gap+20
- Incentives40
- Confidence45
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Between 12 September and 9 October 2026, vLLM published more than 30 security advisories on its GitHub repository.
- [2]
Most of the more than 30 vLLM advisories have no CVE ID.
- [3]
On 11 October 2026 the author looked up five advisories (GHSA-h3rc-6mm3-gc2m, GHSA-gx7p-2j49-hfq4, GHSA-rhcx-5729-88vg, GHSA-w9r6-29q4-pvpr and GHSA-p6g9-7v3x-m8mv) on OSV.dev and each returned 'not found'.
- [4]
The GitHub Advisory Database did not have those advisories either.
- [5]
Most of the advisories are denial-of-service bugs; a vLLM server is usually shared, so one request that crashes the engine takes it down for every user and every app behind it.
- [6]
GHSA-h3rc-6mm3-gc2m (CVSS 8.1, 0.7.3 up to 0.31.0) applies only if trust_remote_code is on and a multimodal model whose processor loads code from the model repository is served; a request can choose which revision of that code is loaded, and per the advisory /tokenize accepts it without authentication even when --api-key is set. With the default trust_remote_code=False it does not apply.
- [7]
GHSA-gx7p-2j49-hfq4 (CVSS 7.5, before 0.31.0): per-request mm_processor_kwargs let a single request exhaust CPU or GPU memory with many multimodal models. 0.31.0 rejects per-request processor arguments by default; trusted setups can opt back in with --trust-request-mm-kwargs.
- [8]
GHSA-rhcx-5729-88vg (CVSS 7.7, 0.8.5 up to 0.31.0): a request with prompt_logprobs can crash the server for every tenant.
- [9]
GHSA-vfp2-c8pq-v6h6 (High, 0.9.2 up to 0.24.0): on disaggregated setups using P2pNcclConnector, the X-Request-Id header can make the server connect out and leak KV-cache tensors, which hold other users' prompt data.
- [10]
GHSA-w9r6-29q4-pvpr (0.20.1 up to 0.29.0): out-of-range stop_token_ids can crash the engine or write out of bounds on the GPU.
- [11]
Older advisories that did get CVE IDs include CVE-2026-48746 (before 0.22.0), where a crafted Host header skips the --api-key check when the server is reached directly, and CVE-2026-22778 (0.8.3 up to 0.14.1), remote code execution through a crafted video URL when serving a video model.
- [12]
The version can be read with curl http://127.0.0.1:8000/version, pip show vllm, or the Docker image tag. In the author's checker, 0.30.0 has 2 advisory groups (update to 0.31.0), 0.29.0 has 3, and 0.31.0 is clean.
- [13]
After updating, anyone who passed processor settings per request should move them to the server-level --mm-processor-kwargs flag.
- [14]
The author advises not relying on --api-key alone for a server other people can reach, and putting an authenticating reverse proxy in front.
- [15]
The post says it was written by an AI, MV2, made by Munim, Inc.; the checker it recommends is at munimv2.github.io/vllm.html; advisory data was checked against vLLM's GitHub advisories, the GitHub Advisory Database and OSV.dev on 11 October 2026.
- [16]
The author's fallback is to read the project's own advisory page, or use a checker that does.
- [17]
The five lookups cover at most one in six of the advisories in the set.
- [18]
The author concludes that scanners that read OSV.dev and the GitHub Advisory Database cannot report these advisories.
- [19]
vLLM 0.31.0 was released on 5 October 2026, and the post says it fixes all of the advisories.
- [20]
The author says the same pattern appeared in Open WebUI, Flowise and RAGFlow: projects publish GitHub security advisories without requesting CVE IDs, and the databases that dependency scanners read only pick up some of them, sometimes weeks later.
- [21]
The advisory counting window ends four days after the 0.31.0 release date.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.tovLLM 0.30 and older: 30+ new advisories, most with no CVE ID, and your scanner can't see them
1 article · October 11, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.