GPU VulnDB

Database/AI/ML frameworks & serving

vLLM: unregistered PyPI name in the official Dockerfile allows dependency confusion into built images

CVSS 8.8CVE-2026-54232AI/ML frameworks & servingcurated

Impact

Anyone building vLLM's own container image before 0.22.1 pulls flashinfer-jit-cache through --extra-index-url with UV_INDEX_STRATEGY=unsafe-best-match, and the package name was never claimed on PyPI. Whoever registered the name on PyPI could have had arbitrary code run as root during the image build, leaving a backdoored serving image that an operator then rolls out across the GPU fleet. On an inference node that means the attacker sits inside the process holding the model weights and every prompt and API key passing through it, with GPU memory and the node's service credentials in reach. Because the compromise is baked into the image rather than into a running config, it survives pod restarts and spreads wherever that image tag is deployed.

Who can reach it

No access to the operator's environment is needed - the attacker only has to publish a package under the unclaimed name on public PyPI. The victim action is building (or pulling a build of) the vLLM Dockerfile; unauthenticated and remote with respect to the operator.

What to do

Rebuild images on vLLM 0.22.1 or later, which fixes the index handling, and redeploy serving pods from the new image; pin and verify the flashinfer index explicitly if you maintain a forked Dockerfile. Rolling the new image out is a serving-pod restart rather than a node reboot, but any image built from an affected Dockerfile should be treated as suspect and replaced, not patched in place. The advisory does not state that a malicious package was ever published.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.