CVE-2026-100653 in vLLM
Summary
by MITRE • 09/26/2026
vLLM is an inference and serving engine for large language models. In versions from 0.22.1 through 0.28.0, the operator-supplied model revision pin (--revision / --code-revision) is not propagated to several Hugging Face artifact loads for the FunAudioChat and Tarsier2 architectures: the WhisperFeatureExtractor and speech_tokenizer PreTrainedTokenizerFast loads in vllm/model_executor/models/funaudiochat.py and the Qwen2VLConfig.from_pretrained call used by Tarsier2ProcessingInfo in vllm/model_executor/models/qwen2_vl.py. As a result, deployments pinned to a reviewed revision still resolve these behavior-affecting processor, tokenizer, and config artifacts from the repository's default revision, so a later change to the upstream default branch can alter audio preprocessing, speech tokenizer behavior, or Tarsier2 configuration without any change to the operator's configured pin. This is a supply-chain integrity and reproducibility failure for pinned deployments; it is residual to the earlier fix tracked as GHSA-3ww4-5jv9-j5gm / CVE-2026-47155 and does not constitute remote code execution or a trust_remote_code=False bypass. The issue is fixed in version 0.28.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in vLLM versions ranging from 0.22.1 through 0.28.0 represents a critical failure in supply chain integrity and deployment reproducibility for large language model inference engines. While the primary function of vLLM is to provide high-performance serving capabilities, this specific flaw undermines the security guarantees provided by pinning model revisions via command-line arguments such as --revision or --code-revision. When an operator explicitly pins a model to a specific revision hash or tag to ensure consistent behavior and mitigate risks associated with upstream changes, the software fails to propagate this constraint across all necessary artifact loads for certain architectures, specifically FunAudioChat and Tarsier2. This inconsistency creates a scenario where the core model weights may be securely pinned, but critical auxiliary components are resolved from the repository's default branch instead of the specified revision.
The technical root cause lies in how specific Hugging Face artifacts are loaded within the vLLM codebase for these architectures. For the FunAudioChat architecture, the WhisperFeatureExtractor and speech_tokenizer PreTrainedTokenizerFast loads do not respect the operator-supplied model revision parameter. Similarly, for the Tarsier2 architecture, the Qwen2VLConfig.from_pretrained call utilized by Tarsier2ProcessingInfo fails to inherit the pinned revision context. Consequently, these behavior-affecting processor, tokenizer, and configuration artifacts are fetched from the default branch of the Hugging Face repository rather than the reviewed and approved revision. This means that any subsequent changes made to the upstream default branch can silently alter audio preprocessing logic, speech tokenization behavior, or Tarsier2 model configurations without any corresponding change to the operator's configured pin settings.
The operational impact of this vulnerability is significant for organizations relying on deterministic inference outcomes and strict security postures. Because auxiliary components like tokenizers and feature extractors directly influence how input data is processed before being fed into the neural network, their modification can lead to unpredictable model behavior, potential alignment drift, or even unintended side effects in downstream applications that depend on consistent preprocessing pipelines. This constitutes a supply-chain integrity failure because the deployed system does not match the audited and approved version of all its dependencies. It allows for a form of indirect manipulation where an attacker who has gained write access to the default branch of a Hugging Face repository could alter these auxiliary artifacts, thereby affecting systems that believe they are running from a secure, pinned revision.
This issue is classified as residual to earlier fixes tracked under GHSA-3ww4-5jv9-j5gm and CVE-2026-47155, which addressed broader trust_remote_code bypasses and remote code execution risks. It is crucial to distinguish this vulnerability from those; it does not constitute a direct remote code execution vector nor does it allow for the bypass of security flags like trust_remote_code=False in the traditional sense. Instead, it represents a subtle but dangerous deviation from expected reproducibility standards. The flaw aligns with CWE-829, which pertains to Inclusion of Functionality from Untrusted Control Sphere, as the system includes functionality (the auxiliary artifacts) that is not fully controlled by the operator's explicit selection criteria. Furthermore, in terms of MITRE ATT&CK mapping, this behavior can be associated with T1587.002, Develop Custom Capabilities: Malicious Code, if an adversary were to manipulate these upstream defaults to introduce subtle biases or backdoors into the preprocessing pipeline that evade standard model weight audits.
Mitigation for this vulnerability requires immediate action by deploying vLLM version 0.28.0 or later, where the propagation of revision pins has been corrected across all relevant artifact loads. For organizations unable to upgrade immediately due to dependency constraints, it is advisable to audit their Hugging Face repository dependencies and consider mirroring specific revisions locally to ensure that no artifacts are resolved from mutable default branches. Additionally, implementing strict CI/CD checks that verify the consistency of revision pins across all model components can help detect such discrepancies before deployment. Regularly reviewing upstream repositories for changes to pinned versions is also recommended as a defense-in-depth measure against supply chain manipulation attempts targeting auxiliary inference components.