High

Supply Chain Unsafe Index Resolution During Package Install

This detects the exact command-line moment when a Python package installer is run with a 'best match across all indexes' setting, or when it installs a specific known-malicious version of the flashinfer-jit-cache package. That setting lets an installer silently prefer a public PyPI package over a private vendor package with the same name and a higher version number, which is how the vLLM/flashinfer-jit-cache dependency confusion attack gets its malicious code pulled in.

How the attack works

An attacker publishes a package on public PyPI with the same name as an internal or vendor-only package, but with a higher version number. A build or install process runs a package installer with an unsafe index strategy (UV_INDEX_STRATEGY=unsafe-best-match or --index-strategy unsafe-best-match), which tells the resolver to pick the highest version across all configured indexes instead of trusting the private index first. Because the attacker's PyPI package outranks the real one, it gets installed instead. In the case this rule is based on, the malicious package was pinned at flashinfer-jit-cache==0.6.11.post2. From there the attacker's code can run with whatever privileges the build or install process has, but this rule does not see that part.

Netzilo detection

Netzilo reports this behaviour when it is observed.

Signature ID
7c1f4a2e-9d63-4b58-8f0a-2ec5d1b73a94
Severity
High

Why it matters

An organization that gets hit ends up running attacker-supplied code during a package install or container build, potentially at root/build-time privilege, which can lead to compromised build artifacts or images being shipped downstream.

What you can do

  • →Search build logs and Dockerfiles for UV_INDEX_STRATEGY=unsafe-best-match or --index-strategy unsafe-best-match and confirm whether it's intentional.
  • →Pin private/vendor packages by exact version and index in lockfiles so a higher-numbered public package cannot silently win resolution.
  • →Check whether flashinfer-jit-cache==0.6.11.post2 or any package with an unexpected origin index was ever installed in your environment.
  • →Configure package installers to require explicit index-per-package mapping instead of a 'best match across all indexes' fallback.

Known benign look-alikes

  • Upstream vLLM and flashinfer container builds that genuinely set UV_INDEX_STRATEGY=unsafe-best-match to mix PyPI with the vendor wheel index. This is the exact configuration the rule exists to surface for review, so it is a true positive on the configuration even when the installed package is legitimate - triage by confirming which index served flashinfer-jit-cache.
  • Internal monorepo builds that intentionally blend a private index with PyPI using the unsafe resolver for legacy pinning reasons.
  • CI jobs that lint, print or grep a Dockerfile / uv.lock containing the flag rather than executing an install (suppressed by filter_inspection).
  • Resolution experiments run with --dry-run or --help while an engineer tunes index settings (suppressed by filter_no_execution).
  • SCA and container scanners whose command lines echo a lockfile entry for the package (suppressed by filter_sca_tooling).

References