CVE-2025-13327

What it actually does

CVE-2025-13327 is a remote-code-execution class flaw in Astral uv involving specially crafted ZIP package archives and parsing differentials during dependency resolution or package installation. If a privileged user or automation context installs an attacker-controlled package, uv may process archive metadata or contents inconsistently in a way that allows attacker-supplied code to execute with the privileges of the invoking user or build process. The CVSS vector indicates local attack context, high attack complexity, high privileges, and required user interaction, but successful exploitation can compromise confidentiality, integrity, and availability of the affected system.

Why it matters to the business

The primary risk is compromise of developer workstations, CI/CD runners, build systems, or packaging workflows when they install untrusted or manipulated Python packages through uv. A successful attack could expose source code, credentials, signing keys, package registry tokens, cloud credentials, or build artifacts, and could allow tampering with software releases. Although the EPSS score is currently low, there is no CISA KEV listing, and no public exploit maturity is reported, package-installation flaws can become impactful in software supply-chain environments because a single compromised build host can affect downstream consumers.

How an attack unfolds

An attacker first creates or modifies a ZIP-based package artifact designed to trigger inconsistent parsing behavior during uv package resolution or installation. The attacker then convinces a user, developer, maintainer, or automation workflow with sufficient privileges to install the attacker-controlled package, for example through a dependency update, direct package reference, poisoned internal package, malicious repository, or social-engineered installation instruction. When uv processes the crafted archive, the parsing differential is triggered and malicious code executes in the context of the user or process running uv. If exploitation occurs on a developer workstation or CI runner, the attacker may then attempt credential theft, source-code access, persistence in build scripts, modification of dependency files, or lateral movement into package registries and deployment systems.

How to fix it

Upgrade Astral uv to a vendor-fixed version as soon as one is available. No fixed version was provided in the supplied advisory data, so organizations should monitor Astral uv release notes, security advisories, package repositories, and distribution channels for the first version that explicitly remediates CVE-2025-13327. Until patched, restrict installation of untrusted packages, require dependencies to come from approved registries, pin and review dependencies, avoid direct installs from arbitrary URLs or local archives, and run uv in least-privileged, isolated environments such as ephemeral containers or sandboxed CI jobs. Treat developer and CI credentials available during package installation as high-risk secrets and minimize their scope.

How to confirm the fix worked

Inventory where Astral uv is installed by checking developer images, CI runners, build containers, base images, and package-management tooling. Confirm the installed uv version with `uv --version` and compare it against the vendor-advised fixed release once published. Validate that package installation workflows only use trusted registries and approved dependency sources. Review dependency manifests and lockfiles for unexpected package additions, direct URL references, local archive references, or recently changed package sources. In CI/CD, confirm package installation runs in isolated jobs with restricted credentials and that build logs are retained for investigation.

Typical attack path

1. Attacker prepares a malicious ZIP package archive that abuses uv archive parsing behavior.
2. Attacker publishes, distributes, or otherwise makes the package available to the target.
3. Target user or automation installs or resolves the attacker-controlled package with uv.
4. uv processes the crafted archive during dependency resolution or installation.
5. Malicious code executes with the privileges of the uv process.
6. Attacker attempts follow-on actions such as stealing credentials, modifying build artifacts, altering dependency manifests, or establishing persistence.

How to detect it

There are no public, vulnerability-specific indicators or known exploited-in-the-wild reports in the supplied data. To determine whether exploitation may have occurred, review endpoint, EDR, shell history, CI/CD, package-manager, and build logs for uv executions involving newly added, unexpected, or externally sourced packages. Focus on commands such as dependency synchronization, package installation, direct URL installation, or installation from local ZIP archives. Examine recent changes to dependency manifests and lockfiles, including unexpected package names, source changes, local archive paths, direct references, or dependency updates introduced shortly before suspicious activity. On affected systems, investigate child processes spawned by uv during installation, unexpected network connections from build jobs or developer shells, credential access attempts, modifications to shell startup files, changes to CI scripts, and writes to package publishing or release directories. If suspicious uv activity is found, preserve the package archive, lockfiles, build logs, process telemetry, and filesystem timeline, and treat exposed repository, registry, cloud, and signing credentials as potentially compromised.

What your security team should do

• Identify all developer workstations, CI runners, build images, and automation jobs using Astral uv.
• Monitor Astral uv advisories and upgrade immediately when a fixed version is published.
• Temporarily block or require review for uv installs from untrusted ZIP files, direct URLs, local archives, forks, and newly introduced package sources.
• Prioritize review of CI/CD workflows and developer environments that have access to source code, signing keys, package-publishing tokens, cloud credentials, or production deployment permissions.
• Enforce dependency pinning, lockfile review, and trusted package index usage for uv-based workflows.
• Run package installation in ephemeral, least-privileged, network-restricted environments where feasible.
• Review recent dependency changes and build logs for unexpected package installations or archive-based installs.
• Rotate credentials if suspicious package installation activity is found on a developer workstation or build system.