# Model Supply Chain - vLLM Incomplete Revision Pinning at Launch

- **Severity:** Medium
- **Signature ID:** `6f1c9a24-7d8e-4b3a-9c05-2ae4f7b18d31`
- **MITRE ATLAS:** AML.T0011 (User Execution)

## Summary

vLLM lets operators pin a model to a specific commit so it can't silently change, but that pin doesn't cover everything. Remote code, GGUF weight files, and companion tokenizer repos can still be pulled from the repository's default branch even when the operator thinks the whole model is locked down.

## How the attack works

An operator launches a vLLM server with a --revision flag pointing to a specific commit, believing this fully pins the model. In reality, several artifact types are not covered by that flag: dynamic remote code (with --trust-remote-code) still runs from the default branch unless --code-revision is also set and immutable; a 'pin' set to a mutable ref like main or HEAD doesn't actually freeze anything; GGUF weight files ignore the --revision setting entirely; and sibling tokenizer or processor repositories load unpinned unless --tokenizer-revision is separately specified. If someone with write access to the repository's default branch pushes malicious code or weights, the server picks it up despite the operator's apparent pinning. The rule looks at the exact launch command of the vLLM process to spot these four incomplete-pinning patterns.

## Why it matters

An attacker who can write to the default branch of a model repository can get unreviewed code or weights loaded into a production inference server that the operator believed was locked to a vetted commit, without changing any launch approval process.

## What you can do

- When using --trust-remote-code, also set --code-revision to an immutable commit hash, not just --revision.
- Never pin to mutable refs like main, master, latest, HEAD, or dev; use a specific commit SHA.
- If loading GGUF weight files, verify the file's hash out of band since --revision does not protect it.
- Set --tokenizer-revision explicitly whenever the tokenizer or processor lives in a separate repository from the main model.

## Known benign look-alikes

- Operator intentionally runs --trust-remote-code against a fully mirrored, internally controlled model repository where the default branch is already change-controlled; the incomplete pin is real but accepted risk.
- Deployment templates that ship '--revision main' as a placeholder which CI substitutes with a commit SHA later in the pipeline; the placeholder value can still reach exec in staging environments.
- GGUF serving where the operator reviewed and hash-verified the .gguf file out of band before launch, so the unpinned GGUF resolution is compensated.
- Evaluation and benchmarking harnesses that deliberately point --tokenizer at a separate hub repo tracking latest while pinning only the model weights.
- Container build or image-lint steps that materialise an example 'vllm serve' command line into a real exec (partially suppressed by the docs, help and inspection filters).

## References

- https://docs.vllm.ai/en/latest/serving/engine_args.html
- https://atlas.mitre.org/techniques/AML.T0011
- https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/

---
Source: https://www.netzilo.com/threats/vllm-revision-pinning-bypass