vLLM CVE-2026-47155
MEDIUM
GHSA-3ww4-5jv9-j5gm
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify operator running pinned vLLM deployment
-
DeliveryGain write access to target HuggingFace model repo default branch
-
ExploitPush malicious secondary artifact (weights, processor, or config) to unpinned default ref
-
ExecutionTrigger model load or restart on victim vLLM host
-
PersistvLLM fetches primary artifact under pinned revision but resolves secondary artifact from compromised default ref
-
ImpactMalicious weights or code execute within inference pipeline
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V15 - Secure Coding and Architecture Data authenticity verification
|
| Exploitation Conditions | Exploitation requires three concurrent conditions: (1) the target vLLM deployment must be launched with an explicit |
| Impact | The CVSS 6.5 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N) signals a network-reachable issue with high integrity impact but also high attack complexity, meaning exploitation requires conditions beyond a simple request-response. The AC:H reflects the real-world prerequisite: an attacker must have write access to, or be able to compromise, the default branch of a HuggingFace model repository to place a malicious artifact on the unpinned ref that a victim deployment would then fetch. This limits the threat actor pool significantly - opportunistic mass exploitation is not realistic. No CISA KEV listing exists and no public exploit code has been identified; the reporter supplied a private verification bundle to the vLLM maintainers but did not publish it. EPSS data was not provided in the source intelligence; given the AC:H and niche operator audience, real-world exploitation probability is likely low despite the high integrity impact score. The I:H score is justified because the artifact loaded could be model weights, dynamic Python code, or processor logic that directly shapes inference output - any of which could be silently modified to produce adversarially controlled responses. The C:L score reflects that indirect model output manipulation could leak information, though direct data exfiltration is not the primary vector. The risk is most acute for operators with formal ML audit, compliance, or security review pipelines who rely on revision pinning as a control; for such operators, the integrity guarantee is completely broken across seven code paths. |
| Exploit ScenarioDerived | An attacker with write access to a publicly hosted HuggingFace model repository (or who has compromised a maintainer account) pushes a modified |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 10, 2026
Artifact pin decay in vLLM (< 0.22.0) allows pinned model deployments to silently load secondary artifacts - dynamic code modules, GGUF files, image processors, retrieval side weights, and same-repository subfolder configs - from unpinned or default HuggingFace Hub revisions, undermining supply-chain integrity guarantees. Operators who supply --revision or --code-revision to audit and lock a specific model version can unknowingly serve behavior-affecting components that fall outside the reviewed artifact set. No public exploit code has been identified at time of analysis, but seven discrete affected code paths across vllm's model loader and registry subsystems have been confirmed at commit 3795d7acf431980e62e738493f437ae2a51549da, with a fix released in vLLM 0.22.0 via PR #42616.
RemediationAI
Upgrade to vLLM 0.22.0, which contains the upstream fix from PR #42616 (https://github.com/vllm-project/vllm/pull/42616). Install via pip install vllm>=0.22.0. The fix enforces consistent revision propagation across all seven identified loader paths. The full security advisory is available at https://github.com/vllm-project/vllm/security/advisories/GHSA-3ww4-5jv9-j5gm. If immediate upgrade is not possible, operators relying on --revision or --code-revision for supply-chain assurance should as a compensating control restrict outbound network access from the vLLM host to HuggingFace Hub endpoints and pre-download all required artifacts to a private, access-controlled model registry (e.g., a local HuggingFace mirror or object store), then serve from local_files_only=True mode. This eliminates the remote resolution path entirely but requires an operational process to manage artifact promotion. Note that disabling trust_remote_code does not mitigate the GGUF, image processor, or side-weight pin-decay paths - only the dynamic code module path - and is therefore insufficient as a standalone workaround.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
vLLM is a high-throughput LLM inference engine (pkg:pip/vllm) that fetches model artifacts from HuggingFace Hub. CWE-345 (Insufficient Verification of Data Authenticity) describes the root cause: when a caller provides a revision pin, vLLM's internal loader and model class code fails to propagate that pin to all downstream artifact fetches. The specific failure points are: registry.py (L1045-1064) passes model_config.revision to _try_resolve_transformers() but omits code_revision, breaking --code-revision enforcement for auto_map dynamic module imports; gguf_loader.py (L58-60) calls hf_hub_download() with no revision argument for the repo/file.gguf path form; roberta.py (L203-209) hard-codes revision=None for BGE-M3 sparse and ColBERT side weights; kimi_k25.py (L111-114) calls cached_get_image_processor() without forwarding model_config.revision; and kimi_audio.py (L92-95, L425-430) loads both the Whisper config and secondary weights for the whisper-large-v3 subfolder with no revision argument. The default_loader.py (L287-301) preserves the primary source revision but blindly consumes secondary sources as declared by the model, meaning any secondary source that drops the pin is trusted without re-enforcement. This is fundamentally a parameter propagation failure across multiple abstraction layers, not a cryptographic or authentication weakness - the 'Authentication Bypass' tag in the source data is misleading for this supply-chain integrity class of issue.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N
Primary rating from Vendor (https://github.com/vllm-project/vllm).
CVSS VectorVendor: https://github.com/vllm-project/vllm
DescriptionCVE.org
Summary
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.
Details
The expected invariant is:
> When a vLLM operator supplies a model or code revision pin, every code, config, processor, weight file, side weight, and same-repository subfolder artifact loaded as part of that model should resolve under that pin unless vLLM exposes and enforces a separate explicit pin for that artifact.
Current main was verified affected at commit 3795d7acf431980e62e738493f437ae2a51549da.
Affected source boundaries:
vllm/model_executor/models/registry.py:1045-1051and:1058-1064_try_resolve_transformers()passesrevision=model_config.revisionandtrust_remote_code=model_config.trust_remote_code, but omitscode_revision=model_config.code_revisionfor externalauto_mapdynamic module imports.vllm/model_executor/model_loader/gguf_loader.py:58-60- The direct-file GGUF form
repo/file.ggufcallshf_hub_download(repo_id=repo_id, filename=filename)without passingrevision. vllm/model_executor/models/roberta.py:203-209- BGE-M3 secondary sparse and ColBERT side weights are declared with
revision=None. vllm/model_executor/models/kimi_k25.py:111-114- Kimi-K2.5 calls
cached_get_image_processor()without passingmodel_config.revision. vllm/model_executor/models/kimi_audio.py:92-95- Kimi-Audio loads Whisper config from the
whisper-large-v3subfolder without arevisionargument. vllm/model_executor/models/kimi_audio.py:425-430- Kimi-Audio declares same-repository
whisper-large-v3secondary weights withrevision=None. vllm/model_executor/model_loader/default_loader.py:287-301- The default loader preserves
model_config.revisionfor the primary source, then consumes model-supplied secondary sources as declared.
The strongest example is Kimi-Audio: the primary moonshotai/Kimi-Audio-7B-Instruct weights preserve the configured model revision, but the same-repository whisper-large-v3 audio tower config/weights do not. A pinned Kimi-Audio deployment can therefore load the Whisper subfolder outside the audited revision.
This report does not claim a trust_remote_code=False bypass, unauthenticated RCE, or real artifact compromise. The issue is improper propagation of explicit artifact pins across supported loader paths.
Impact
Affected users are operators who pin vLLM model deployments to a reviewed Hugging Face revision for safety review, provenance, rollback, or reproducibility. The impact is that the pin does not reliably describe the full set of artifacts vLLM serves. Even when the operator selects an audited revision, vLLM can resolve behavior-affecting secondary artifacts from the repository default branch or another mutable ref.
Depending on the model path, the unpinned artifact can be dynamic model code, a GGUF file, an image processor, retrieval side weights, or the same-repository Kimi-Audio Whisper subfolder weights/config.
This breaks the operational guarantee of a pinned deployment: "serve the exact artifact set I reviewed." A later change to an unpinned secondary artifact can alter model behavior without changing the operator's configured revision, making review, rollback, incident response, and audit records unreliable.
Occurrences
vllm/model_executor/models/kimi_k25.pyL111-L114 - Kimi-K2.5 loads its image processor withcached_get_image_processor()but does not passself.ctx.model_config.revision. The processor can therefore resolve from the default repository revision even when the model deployment is pinned.vllm/model_executor/models/kimi_audio.pyL425-L430 - Kimi-Audio declares same-repositorywhisper-large-v3secondary weights withrevision=None. A pinned Kimi-Audio deployment can therefore load the Whisper audio tower weights from an unpinned/default revision.vllm/model_executor/models/kimi_audio.pyL92-L95 - Kimi-Audio loads Whisper config from the same repository'swhisper-large-v3subfolder without passing the top-level model revision. The config for this behavior-affecting subcomponent can be resolved outside the audited model revision.vllm/model_executor/models/registry.pyL1058-L1064 - The later dynamic model-class resolution repeats the same pin-decay pattern: it forwardsrevisionandtrust_remote_code, but omitscode_revision. This means an operator-provided code pin is not enforced at the dynamic module loader boundary.vllm/model_executor/model_loader/gguf_loader.pyL58-L60 - The direct GGUF formrepo/file.ggufcallshf_hub_download(repo_id=repo_id, filename=filename)without passingmodel_config.revision. A deployment that pins the model revision can therefore resolve this GGUF file from the repository default revision.vllm/model_executor/models/registry.pyL1045-L1051 -try_get_class_from_dynamic_module()is called for externalauto_mapconfig/model classes withrevision=model_config.revision, but without forwardingmodel_config.code_revision. When--code-revisionis set, this dynamic module resolution can still fall back to the default code revision instead of the audited code revision.vllm/model_executor/models/roberta.pyL203-L209 -BgeM3EmbeddingModelcreates same-repository secondary sparse/ColBERT weight sources withrevision=None. The primary model revision is not propagated to these side weights, so they can be downloaded outside the operator-selected model revision.
Fixes
This was fixed in: https://github.com/vllm-project/vllm/pull/42616
___
Originally filed via huntr: https://huntr.com/bounties/3f1e24c0-87d2-4f6c-a705-820f380879ac.
The vLLM maintainer (Russell Bryant) redirected the report to the private GHSA channel. Offline proof bundle (vllm_artifact_pin_decay_bundle_verify.py + bundle-verification-20260430T143506Z.json) is available upon request.
Blast Radius
ecosystem impact- 1 pypi packages depend on vllm (1 direct, 0 indirect)
Ecosystem-wide dependent count for version 0.22.0.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB