vLLM: Prior to 0.22.1, the vLLM Dockerfile is vulnerable to a dependency confusion attack through the…
vLLM
More for vLLM RSS feed for vLLM
- Severity
- High, CVSS 8.8
- CVSS vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
- Record
- CVE-2026-54232
- Affects
- vLLM
- Known exploited
- Not listed in the CISA Known Exploited Vulnerabilities catalog
- Published
- Record first published by the source
- June 22, 2026
- Source last modified
- October 25, 2026
Description
vLLM is an inference and serving engine for large language models (LLMs). Prior to 0.22.1, the vLLM Dockerfile is vulnerable to a dependency confusion attack through the flashinfer-jit-cache package. The package is installed from a custom index (flashinfer.ai/whl/) using --extra-index-url, but the package name was not registered on PyPI, and UV_INDEX_STRATEGY="unsafe-best-match" is set globally. An attacker who registers flashinfer-jit-cache on PyPI with version 0.6.11.post2 can execute arbitrary code as root during the Docker build and backdoor every resulting container image, enabling exfiltration of all user prompts, API credentials, and model data from production vLLM deployments This vulnerability is fixed in 0.22.1.
Description quoted from the NVD record.
Who is affected
vLLM is software that runs AI language models so that other apps can use them. This flaw affects versions before 0.22.1. It lies in the official recipe used to build vLLM container images, which are ready-to-run packages of the software. One add-on package, flashinfer-jit-cache, could be pulled from the public Python package library instead of its intended source. An attacker who publishes a package with that name could run their own code with full control while the image is built, planting a hidden backdoor. That could let them steal user prompts, login details, access keys and model data from live systems. This flaw is rated High.
What to do
- Find out who installed or runs vLLM for your organization. This may be someone on your staff, or an IT provider or vendor that manages it for you.
- If you run vLLM yourself, update it to version
0.22.1, which fixes this flaw. - If your organization builds its own vLLM container images, build them again from version
0.22.1so they no longer use the unsafe recipe. - If an IT provider or vendor runs vLLM for you, send them this advisory and ask when the update will be done.
- For more detail, read the vendor advisory linked on this page.
Analysis written from the source record as of October 25, 2026 and reviewed before publishing.