CVE-2025-54368

What it actually does

The flaw is an improper ZIP archive validation issue in uv versions 0.8.5 and earlier. uv processed remote ZIP archives streamwise without reconciling extracted local file entries against the ZIP central directory. A malicious archive could contain duplicate, conflicting, or stacked ZIP entries so that uv extracted different content than another package installer would. This allows an attacker to target installer-specific parsing behavior and cause uv to install malicious package files while the archive may appear benign when inspected or installed with a different tool. The primary impact is high integrity compromise of installed Python package contents; confidentiality and availability impact are not the direct vulnerability outcome.

Why it matters to the business

This is a software supply-chain integrity issue: developers, CI jobs, or build systems that install Python packages from remote ZIP archives using vulnerable uv versions could unknowingly build, test, or ship software containing attacker-controlled code. Because exploitation requires a user or automated process to install a malicious archive, exposure is highest where dependencies are accepted from URLs, untrusted package sources, pull requests, build scripts, or generated lockfiles. It is not currently listed in CISA KEV, has no known ransomware association, and has a low EPSS score, but the consequence can still be serious in build and release pipelines because a single poisoned dependency can propagate into downstream artifacts.

How an attack unfolds

An attacker prepares a specially crafted ZIP package containing ambiguous ZIP structures, such as multiple local file entries for the same path or stacked internal ZIP content. The archive is designed so that it appears to contain legitimate package files when examined or installed by one tool, while uv 0.8.5 or earlier extracts a different set of files. The attacker then convinces a victim, build job, or dependency workflow to install the archive through uv, commonly by publishing or linking a remote ZIP dependency, submitting a pull request that references the archive, compromising a package source, or influencing a lockfile or build configuration. When vulnerable uv installs the archive, malicious files can be written into the package environment and later executed through normal Python package behaviors such as imports, build hooks, console scripts, or test execution.

How to fix it

Upgrade uv to version 0.8.6 or later. For source-based astral-sh/uv deployments, ensure the fix containing commit 329a6b446a8619bd055cce1dd402a0cd0de6e7bb is present. For Chainguard packages, upgrade flux-2.5 and flux-2.5-compat to 2.5.1-r13 or later. Rebuild containers, developer images, CI runners, and build environments that bundle uv. Avoid installing Python packages directly from untrusted remote ZIP URLs; prefer pinned package indexes, verified hashes, signed artifacts, and reviewed lockfiles. Do not set UV_INSECURE_NO_ZIP_VALIDATION=1 as a mitigation; that environment variable disables the safer validation behavior and should only be used, if at all, as a temporary compatibility exception with compensating controls and trusted inputs only.

How to confirm the fix worked

Confirm that all uv installations report version 0.8.6 or later using `uv --version`, and verify container images or system packages include the fixed Chainguard package versions where applicable. Review CI images, base images, developer bootstrap scripts, and dependency installation workflows for embedded uv binaries. Test dependency installation workflows that use ZIP archives and ensure they fail closed on malformed archives with duplicate or inconsistent entries. Search build configurations and environment definitions for UV_INSECURE_NO_ZIP_VALIDATION and remove it unless there is a documented, time-limited exception. Validate that dependency sources are pinned to trusted indexes or hashes and that remote ZIP URL dependencies are either eliminated or explicitly reviewed.

Typical attack path

1. Identify a target workflow that uses uv 0.8.5 or earlier to install Python packages or project dependencies from remote ZIP archives.
2. Create a ZIP archive with ambiguous structure, such as duplicate local file entries or stacked ZIP content, where uv extracts attacker-chosen files.
3. Make the archive appear benign to reviewers or alternate package tools by ensuring its central directory or alternate interpretation shows legitimate content.
4. Introduce the archive into a dependency workflow through a URL dependency, package metadata, pull request, lockfile change, artifact repository, or compromised package source.
5. Trigger installation with vulnerable uv in a developer workstation, CI pipeline, container build, or release process.
6. Rely on normal package execution paths, such as imports, setup/build behavior, scripts, or tests, to execute or propagate the malicious package content.

How to detect it

Investigate whether vulnerable uv versions installed remote ZIP-based dependencies, especially in CI/CD, release, and container build environments. Useful log sources include CI job logs, package installation logs, shell history, build system audit logs, artifact repository download logs, proxy logs, EDR process command-line telemetry, container build logs, and source-control changes to dependency files. Look for `uv` commands that install from `http://` or `https://` URLs ending in `.zip`, recently added direct URL dependencies in `pyproject.toml`, `requirements.txt`, `uv.lock`, or build scripts, and failed or unusual package validation messages after upgrading. For forensic review, preserve the downloaded ZIP artifacts and inspect them for duplicate local file entries, mismatches between local file headers and the central directory, repeated file paths, nested ZIP structures, or package files that differ from the reviewed source. Also look for suspicious package execution artifacts after installation, such as unexpected console scripts, modified Python modules, unexpected build hooks, new outbound network connections during builds/tests, or unexplained changes in generated artifacts. Because this vulnerability enables package-content substitution rather than a fixed malware payload, there are no universal file hashes or network indicators; detection should focus on vulnerable installer use plus ambiguous ZIP inputs and unexpected package behavior.

• UV_INSECURE_NO_ZIP_VALIDATION
• UV_INSECURE_NO_ZIP_VALIDATION=1
• uv pip install http://
• uv pip install https://
• uv add http://
• uv add https://
• .zip
• direct_url.json
• uv.lock
• pyproject.toml
• requirements.txt

What your security team should do

• Prioritize upgrading uv in CI/CD runners, release pipelines, container build images, and developer base images to 0.8.6 or later.
• Inventory use of uv 0.8.5 and earlier across repositories, build scripts, Dockerfiles, GitHub Actions, GitLab CI, Jenkins agents, and packaged images.
• Hunt for Python dependencies installed from direct remote ZIP URLs, especially those introduced recently through pull requests or lockfile changes.
• Block or require approval for untrusted direct URL dependencies and enforce hash-pinned dependency installation where feasible.
• Search for and remove UV_INSECURE_NO_ZIP_VALIDATION from CI variables, shell profiles, container images, and build configurations.
• Rebuild and redeploy artifacts produced by vulnerable build environments if they consumed untrusted ZIP dependencies.
• Add CI policy checks to flag ambiguous archive inputs, direct URL package references, and unexpected changes to dependency lockfiles.
• Monitor package installation logs and build provenance for newly introduced ZIP-based dependencies or artifacts fetched from unfamiliar domains.