OR
          *cpe:2.3:a:vllm:vllm:*:*:*:*:*:*:*:* versions up to (excluding) 0.22.0

GitHub, Inc.: https://github.com/vllm-project/vllm/commit/d26a28ab033697f55a1414b5b0435de7cd6045b6 Types: Patch

GitHub, Inc.: https://github.com/vllm-project/vllm/pull/42616 Types: Issue Tracking

GitHub, Inc.: https://github.com/vllm-project/vllm/security/advisories/GHSA-3ww4-5jv9-j5gm Types: Third Party Advisory

GitHub, Inc.: https://huntr.com/bounties/3f1e24c0-87d2-4f6c-a705-820f380879ac Types: Third Party Advisory

{"timestamp":"2026-06-23T12:34:39.566846Z","id":"CVE-2026-47155","options":[{"exploitation":"none"},{"automatable":"no"},{"technicalImpact":"partial"}],"role":"CISA Coordinator","version":"2.0.3"}

vLLM is an inference and serving engine for large language models (LLMs). Prior to 0.22.0, vLLM's revision pinning controls do not consistently apply to all artifacts loaded for a model. A deployment that supplies --revision or --code-revision can still load dynamic code, GGUF files, image processors, retrieval side weights, or same-repository subfolder weights/config from an unpinned/default revision. This is a supply-chain integrity issue for pinned vLLM deployments. Operators can believe they are serving a reviewed model revision while vLLM resolves behavior-affecting nested or sibling artifacts outside that reviewed revision. This vulnerability is fixed in 0.22.0.

AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N

CWE-345

https://github.com/vllm-project/vllm/commit/d26a28ab033697f55a1414b5b0435de7cd6045b6

https://github.com/vllm-project/vllm/pull/42616

https://github.com/vllm-project/vllm/security/advisories/GHSA-3ww4-5jv9-j5gm

https://huntr.com/bounties/3f1e24c0-87d2-4f6c-a705-820f380879ac

[{"vendor":"vllm-project","product":"vllm","versions":[{"version":"< 0.22.0","status":"affected"}]}]