Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
By default, uv verifies TLS connections against a vendored copy of the webpki-root-certs bundle. Versions before 0.13.4 include the emSign ECC Root CA - G3 root. Eight eMudhra intermediate CA certificates that chain to that root have compromised private keys, and the CA has revoked them. An attacker with one of the compromised keys can issue certificates that uv accepts for any hostname, and can be used to issue certificates to enable MITM attacks. uv 0.13.4 removes the root from its vendored bundle, following webpki-root-certs 1.0.10. Upgrade to 0.13.4 or later.
Recommended action: Upgrade to 0.13.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In versions of uv from 0.12.7 to 0.12.18 on Windows, uv could be induced into writing a file outside of the installation prefix during wheel installation. A malicious wheel could use this to place an executable outside of the intended environment, including in a directory already present on the user's PATH. This vulnerability only affects Windows hosts; no other platforms are affected. Patches uv 0.12.18 and newer address this vulnerability. Users are encouraged to upgrade to 0.12.18. Workarounds There is no workaround other than upgrading to uv 0.12.18.
Recommended action: Upgrade to 0.12.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In versions of uv prior to 0.11.15, when installing a distribution containing an entry point specification (under consolescripts or guiscripts), uv would place the generated entry point according to the given name even if doing so resulted in a path outside of the environment's scripts directory. A malicious wheel could use this to place an executable outside of the intended environment, including in a directory already present on the user's PATH. This could shadow or overwrite an existing executable and potentially result in unexpected code execution under the wheel's control, even if the wheel's installation environment was not explicitly added to PATH by the user. In order to exploit this vulnerability, the attacker must induce their target into installing a malicious wheel. Patches uv 0.11.15 and newer address this vulnerability. Users are encouraged to upgrade to 0.11.15. Workarounds There is no workaround other than upgrading to uv 0.11.15.
Recommended action: Upgrade to 0.11.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wheel RECORD entries can contain relative paths that traverse outside of the wheel’s installation prefix. In versions 0.11.5 and earlier of uv, these wheels were not rejected on installation and the RECORD was respected without validation on uninstall. uv uses the RECORD to determine files to remove on uninstall. Consequently, a malicious or malformed wheel could induce deletion of arbitrary files outside of the wheel’s installation prefix on uninstall. uv does not use the RECORD file to determine wheel file paths. Invalid RECORD entries cannot be used to create or modify files in arbitrary locations. Standards-compliant Python packaging tooling does not produce RECORD files that exhibit this behavior; an attacker must manually manipulate the RECORD. A user must install and uninstall the malformed wheel to be affected. An attack must guess the depth of the installation prefix path in order to target system files. Absolute paths in RECORD files are not allowed by the…
Recommended action: Upgrade to 0.11.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In versions 0.9.5 and earlier of uv, ZIP archives were handled in a manner that enabled two parsing differentials against other components of the Python packaging ecosystem: 1. Central directory entries in a ZIP archive can contain comment fields. However, uv would assume that these fields were not present, since they aren't widely used. Consequently, a ZIP archive could be constructed where uv would interpret the contents of a central directory comment field as ZIP control structures (such as a new central directory entry), rather than skipping over them. 2. Both local file entries and central directory entries contain filename fields, which are used to place archive members on disk. These fields are arbitrary sequences of bytes, and may therefore be invalid or ambiguous. For example, they may contain ASCII null bytes, in which case different ZIP extractors behave differently: Python's zipfile module truncates the filename at the first null, while uv would skip (not extract)…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In versions 0.9.4 and earlier of uv, tar archives containing PAX headers with file size overrides were not handled properly. As a result, an attacker could contrive a source distribution (as a tar archive) that would extract differently when installed via uv versus other Python package installers. The underlying parsing differential here originates with astral-tokio-tar, which disclosed this vulnerability as CVE-2025-62518. In practice, the impact of this vulnerability is low: only source distributions can be formatted as tar archives, and source distributions execute arbitrary code at build/installation time by definition. Consequently, a parser differential in tar extraction is strictly less powerful than the capabilities already exposed to an attacker who has the ability to control source distributions. However, this particular source of malleability in source distributions is unintentional and not operating by design, and therefore we consider it a vulnerability despite…
Recommended action: Upgrade to 0.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In versions 0.8.5 and earlier of uv, remote ZIP archives were handled in a streamwise fashion, and file entries were not reconciled against the archive's central directory. This enabled two parser differentials against other Python package installers: 1. An attacker could contrive a ZIP archive that would extract with legitimate contents on some package installers, and malicious contents on others due to multiple local file entries. The attacker could choose which installer to target. 2. An attacker could contrive a "stacked" ZIP input with multiple internal ZIPs, which would be handled differently by different package installers. The attacker could choose which installer to target. In both cases, the outcome is that an attacker can produce a ZIP with a consistent digest that expands differently with different installers. The ZIP standard is ambiguous with respect to these behavior differentials. Consequently, these same differentials may be accepted ZIP parsers other than…
Recommended action: Upgrade to 0.8.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.