CVE-2026-54232info

Summary

by MITRE • 06/23/2026

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.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 06/23/2026

The vLLM inference engine for large language models contains a critical dependency confusion vulnerability that enables remote code execution during Docker image building. This flaw exists in versions prior to 0.22.1 where the build process uses a custom package index at flashinfer.ai/whl/ through the --extra-index-url parameter. The vulnerability stems from the absence of proper package name validation and the unsafe global configuration UV_INDEX_STRATEGY="unsafe-best-match" which allows the system to prioritize packages from the custom index over PyPI when package names match, creating an attack surface for malicious actors.

The technical implementation of this vulnerability relies on the specific packaging behavior within Python's dependency resolution system where a malicious actor can register a package named flashinfer-jit-cache on the official PyPI repository. When the Docker build process executes with the unsafe index strategy enabled, it will resolve the dependency from PyPI rather than the intended custom index, allowing an attacker to supply a backdoored version of the package that executes arbitrary code as root during container image construction. This represents a classic dependency confusion attack pattern where legitimate package names are hijacked to deliver malicious payloads.

The operational impact of this vulnerability extends beyond simple code execution to complete system compromise of production deployments. Every vLLM container built with affected versions becomes inherently compromised, creating persistent backdoors that can be exploited for data exfiltration and unauthorized access. Attackers gain the ability to intercept all user prompts, API credentials, and model data flowing through these systems, effectively turning every deployment into a potential data breach vector. The root-level execution during build time ensures that any malicious code injected into the container image will run with full system privileges, providing attackers with complete control over the deployed infrastructure.

The vulnerability aligns with CWE-471 which describes the weakness of using an incorrect identifier in a context where a different identifier is expected, and maps to ATT&CK technique T1133 for External Remote Services and T1059.1.001 for Command and Scripting Interpreter. Mitigation requires immediate upgrade to vLLM version 0.22.1 which resolves the issue through proper package validation and removal of the unsafe index strategy configuration. Organizations should also implement strict package repository policies, utilize trusted package sources, and consider implementing dependency lock files to prevent similar attacks in other software systems. The fix demonstrates the importance of secure software supply chain practices where automated build processes must validate package integrity and source authenticity before execution.

Additional security measures include enforcing package name uniqueness verification, implementing proper index strategy configuration with explicit trust boundaries, and conducting regular security audits of container build processes. Organizations should also consider implementing software composition analysis tools to monitor for vulnerable dependencies and establish secure development practices that prevent similar dependency confusion scenarios in other critical infrastructure components.

Disclosure

06/23/2026

Moderation

in review

EPSS

0.00000

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!