CVE-2026-47155: vLLM Revision Pinning Supply-Chain Integrity Bypass (CVSS 6.5)

Technical summary

The vulnerability stems from incomplete revision pinning enforcement in vLLM's artifact resolution logic. While the --revision and --code-revision flags correctly pin the primary model artifacts, the engine's loading mechanisms for dependent resources—including GGUF quantized weights, dynamic code imports, image processor modules, retrieval augmented generation (RAG) side weights, and same-repository subfolder configurations—bypass or ignore the pinned revision constraint. These artifacts resolve to the repository's default branch or latest revision instead. The issue affects any deployment relying on revision pinning as a supply-chain control boundary. Fixed in version 0.22.0 by consistently applying revision constraints across all artifact loading paths.

Business impact

For organizations deploying vLLM in production, this vulnerability undermines a critical security control: the ability to lock model deployments to reviewed and approved revisions. This is especially problematic in regulated environments (finance, healthcare) or when serving proprietary models. An attacker gaining commit access to the model repository—or any insider with repository write permissions—could inject malicious code, poisoned weights, or manipulated configurations that load silently alongside a pinned 'safe' model revision. The impact ranges from model manipulation (inference poisoning, output corruption) to remote code execution if dynamic code modules are compromised. Organizations operating under the assumption that pinned revisions guarantee artifact integrity face unexpected exposure.

Affected systems

vLLM versions prior to 0.22.0 are affected. Any deployment using --revision or --code-revision flags to pin model revisions is at risk, particularly those serving models from shared or untrusted repositories. The vulnerability is most critical in multi-tenant or cloud-hosted vLLM deployments where model repositories may be accessed by or writable by multiple parties. Self-hosted vLLM instances behind trusted network boundaries have reduced but non-zero risk.

Exploitability

Exploitability requires write access to the model repository or its dependent artifact storage. For public models on platforms like Hugging Face, this typically means compromising a model maintainer's account or exploiting repository permissions. The attack is not remotely exploitable against a properly isolated vLLM instance without repository access, but it does not require knowledge of the pinned revision—the attacker simply poisons the default/latest artifacts, betting that they will be loaded. No user interaction is required; exploitation occurs automatically during model load. The CVSS score of 6.5 (MEDIUM) reflects the high integrity impact balanced against the prerequisite need for repository compromise.

Remediation

Upgrade vLLM to version 0.22.0 or later immediately. This version enforces revision pinning consistently across all artifact loading paths, ensuring that --revision and --code-revision flags apply uniformly to dynamic code, GGUF files, image processors, RAG weights, and configuration files. Review current pinned deployments to ensure they are operating on the patched version. Additionally, implement repository access controls to limit who can commit to model repositories, use code signing for critical model artifacts, and consider pinning to specific commit hashes rather than branch names to further tighten supply-chain controls.

Patch guidance

Upgrade vLLM from any pre-0.22.0 release to 0.22.0 or later. Test the upgraded version in a staging environment to confirm that existing deployments continue to function correctly; while the patch enforces stricter revision pinning, legitimate workflows should not be affected. If you are using a pre-release or development version of vLLM, verify the release notes against the official vLLM repository to confirm the fix is included. Container image tags and Python package versions should be explicitly pinned to 0.22.0+ in your deployment manifests.

Detection guidance

Audit your vLLM deployments to identify which versions are in use and whether they employ --revision or --code-revision flags. Monitor model repository access logs for unexpected commits or changes to dependent artifacts (especially in .gitignore'd or dynamically loaded paths). Implement file integrity monitoring on cached model artifacts to detect unauthorized modifications. In development and testing, verify that pinned revisions do not inadvertently load sibling or default-branch artifacts by inspecting the actual files served during inference. Logging and observability around artifact resolution can help detect if unintended revisions are being loaded.

Why prioritize this

Although the CVSS score is MEDIUM, this vulnerability should be prioritized higher in environments where model integrity is a compliance or security requirement. The attack vector—repository compromise—is not uncommon in open-source ecosystems, and the impact (code execution, model poisoning) is severe. Organizations using vLLM for sensitive applications should treat this as a high-priority patch. The fact that it is not yet in the CISA KEV catalog does not diminish its criticality for enterprises relying on pinned model revisions as a supply-chain control.

Risk score, explained

The CVSS 3.1 score of 6.5 (MEDIUM) reflects: high integrity impact (malicious code or weights can be injected), low confidentiality impact (the vulnerability does not leak data), zero availability impact, network-accessible attack surface, high attack complexity (requires repository write access), and no privileges or user interaction required. The score appropriately emphasizes that this is a supply-chain integrity issue rather than a direct confidentiality or availability breach, but the integrity impact and the stealthy nature of the attack (pinning is bypassed silently) warrant careful attention.

Frequently asked questions