CVE-2026-54232: vLLM dependency confusion RCE

CISO Take

A dependency confusion vulnerability in vLLM's Dockerfile allows any attacker who registers the unclaimed `flashinfer-jit-cache` package on PyPI to execute arbitrary code as root during every Docker build of vLLM prior to 0.22.1. The root cause is `UV_INDEX_STRATEGY="unsafe-best-match"` combined with the package name being unregistered on PyPI — a low-barrier attack requiring only a PyPI account and a versioned package upload. Any organization self-building vLLM container images is at risk of deploying persistently backdoored inference infrastructure, with the attacker gaining the ability to exfiltrate all user prompts, API credentials, and model weights in real time from production deployments. Upgrade to vLLM 0.22.1 immediately; if that is not possible, set `UV_INDEX_STRATEGY=first-index` in your build environment and audit all existing container images built before the patch date.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

HIGH. The attack requires trivial capability — PyPI account creation and package publication — yet yields root code execution inside every Docker build of a widely deployed LLM inference engine. The `unsafe-best-match` UV index strategy is the critical misconfiguration that turns an unregistered package name into an exploitable primitive. Because the attack lands during the build phase, runtime security controls (AppArmor, seccomp, network policies) offer zero protection against the initial compromise. The blast radius covers every team that builds vLLM images from source, and backdoored images may already be in production registries.

How does the attack unfold?

Reconnaissance

Attacker inspects vLLM's public Dockerfile and discovers that `flashinfer-jit-cache` is installed from a custom index but the package name is unclaimed on PyPI.

AML.T0095.000

Staging

Attacker registers a PyPI account and publishes `flashinfer-jit-cache==0.6.11.post2` containing a malicious build-time payload (backdoor installer or data exfiltration agent).

AML.T0011.001

Initial Access

Any Docker build of vLLM prior to 0.22.1 silently installs the malicious PyPI package as root; UV_INDEX_STRATEGY=unsafe-best-match selects the higher PyPI version over the legitimate custom-index package.

AML.T0010.001

Impact

Backdoored container images are pushed to registries and deployed to production GPU clusters, enabling persistent exfiltration of all user prompts, API credentials, and model weights from every vLLM inference endpoint.

AML.T0025

Reconnaissance

Attacker inspects vLLM's public Dockerfile and discovers that `flashinfer-jit-cache` is installed from a custom index but the package name is unclaimed on PyPI.

AML.T0095.000

Staging

Attacker registers a PyPI account and publishes `flashinfer-jit-cache==0.6.11.post2` containing a malicious build-time payload (backdoor installer or data exfiltration agent).

AML.T0011.001

Initial Access

Any Docker build of vLLM prior to 0.22.1 silently installs the malicious PyPI package as root; UV_INDEX_STRATEGY=unsafe-best-match selects the higher PyPI version over the legitimate custom-index package.

AML.T0010.001

Impact

Backdoored container images are pushed to registries and deployed to production GPU clusters, enabling persistent exfiltration of all user prompts, API credentials, and model weights from every vLLM inference endpoint.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	—	No patch
83.4K 130 dependents Pushed yesterday 34% patched ~32d to patch Full package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR None

UI Required

S Unchanged

C High

I High

A High

What should I do?

6 steps

Upgrade to vLLM 0.22.1 — the fix claims the package name on the correct index and hardens the UV index strategy.
If immediate upgrade is blocked, set UV_INDEX_STRATEGY=first-index in Dockerfile ENV declarations to prevent fallback to PyPI for custom-index packages.
Audit all Docker images built from vLLM Dockerfiles prior to the patch: use docker history --no-trunc <image> to inspect the layer that installs flashinfer and check for unexpected network calls or file writes.
Scan existing running containers with Trivy or Grype for known malicious indicators.
Rotate all secrets (API keys, database credentials, model registry tokens) that were accessible inside containers built from affected images.
Integrate a software composition analysis (SCA) tool into your CI/CD pipeline with dependency confusion detection rules to catch unregistered custom-index packages going forward.

How is it classified?

Supply Chain Code Execution Data Extraction Inference Framework AML.T0010.001 - AI Software AML.T0010.004 - Container Registry AML.T0011.001 - Malicious Package AML.T0021 - Establish Accounts AML.T0025 - Exfiltration via Cyber Means

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.1.3 - AI system supply chain

NIST AI RMF

GOVERN 1.1 - AI risk management policies MANAGE 2.2 - Risk treatments including response

OWASP LLM Top 10

LLM03:2025 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-54232?

A dependency confusion vulnerability in vLLM's Dockerfile allows any attacker who registers the unclaimed `flashinfer-jit-cache` package on PyPI to execute arbitrary code as root during every Docker build of vLLM prior to 0.22.1. The root cause is `UV_INDEX_STRATEGY="unsafe-best-match"` combined with the package name being unregistered on PyPI — a low-barrier attack requiring only a PyPI account and a versioned package upload. Any organization self-building vLLM container images is at risk of deploying persistently backdoored inference infrastructure, with the attacker gaining the ability to exfiltrate all user prompts, API credentials, and model weights in real time from production deployments. Upgrade to vLLM 0.22.1 immediately; if that is not possible, set `UV_INDEX_STRATEGY=first-index` in your build environment and audit all existing container images built before the patch date.

Is CVE-2026-54232 actively exploited?

No confirmed active exploitation of CVE-2026-54232 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-54232?

1. Upgrade to vLLM 0.22.1 — the fix claims the package name on the correct index and hardens the UV index strategy. 2. If immediate upgrade is blocked, set UV_INDEX_STRATEGY=first-index in Dockerfile ENV declarations to prevent fallback to PyPI for custom-index packages. 3. Audit all Docker images built from vLLM Dockerfiles prior to the patch: use `docker history --no-trunc <image>` to inspect the layer that installs flashinfer and check for unexpected network calls or file writes. 4. Scan existing running containers with Trivy or Grype for known malicious indicators. 5. Rotate all secrets (API keys, database credentials, model registry tokens) that were accessible inside containers built from affected images. 6. Integrate a software composition analysis (SCA) tool into your CI/CD pipeline with dependency confusion detection rules to catch unregistered custom-index packages going forward.

What systems are affected by CVE-2026-54232?

This vulnerability affects the following AI/ML architecture patterns: LLM inference serving, containerized model serving, CI/CD model build pipelines, multi-tenant LLM API deployments, on-premises LLM infrastructure.

What is the CVSS score for CVE-2026-54232?

CVE-2026-54232 has a CVSS v3.1 base score of 8.8 (HIGH).

What is the AI security impact?

Affected AI Architectures

LLM inference servingcontainerized model servingCI/CD model build pipelinesmulti-tenant LLM API deploymentson-premises LLM infrastructure

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0010.004 Container Registry

AML.T0011.001 Malicious Package

AML.T0021 Establish Accounts

AML.T0025 Exfiltration via Cyber Means

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.1.3

NIST AI RMF: GOVERN 1.1, MANAGE 2.2

OWASP LLM Top 10: LLM03:2025

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An adversary searches public vLLM Dockerfile history and discovers that `flashinfer-jit-cache` is installed from `flashinfer.ai/whl/` but the name is unregistered on PyPI. They create a PyPI account and publish `flashinfer-jit-cache==0.6.11.post2` — a version number higher than any on the custom index — with a malicious `setup.py` that downloads and installs a persistent backdoor agent during package installation. Because `UV_INDEX_STRATEGY=unsafe-best-match` directs uv/pip to select the highest available version regardless of index, every subsequent `docker build` across every downstream team's CI/CD pipeline silently installs the malicious package as root. The resulting images are pushed to corporate container registries and deployed to production GPU clusters, where the backdoor begins streaming user prompts and API credentials to the attacker's C2 infrastructure.

Weaknesses (CWE)

CWE-427 Uncontrolled Search Path Element Primary CWE-427 Uncontrolled Search Path Element

CWE-427 — Uncontrolled Search Path Element: The product uses a fixed or controlled search path to find resources, but one or more locations in that path can be under the control of unintended actors.

[Architecture and Design, Implementation] Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as CWE-426 and CWE-428.
[Implementation] When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths.

Source: MITRE CWE corpus.