GHSA-PJJW-68HJ-V9MW

Vulnerability from github – Published: 2026-04-10 19:39 – Updated: 2026-04-10 19:39
VLAI
Summary
uv vulnerable to arbitrary file deletion through RECORD entries
Details

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 specification and, when present, uv always treats them as rooted in the wheel’s installation prefix. Absolute paths cannot be used to delete arbitrary files.

Only files can be deleted, attempts to delete a directory via an invalid RECORD entry will fail.

Patches

Versions 0.11.6 and newer of uv address the validation gap above, by removing invalid entries from RECORD files on wheel installation and ignoring RECORD paths that would escape the installation prefix on uninstall.

Workarounds

Users are advised to upgrade to 0.11.6 or newer to address this advisory.

Users should experience no breaking changes as a result of the patch above.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.11.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "uv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T19:39:15Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Impact\n\nWheel RECORD entries can contain relative paths that traverse outside of the wheel\u2019s 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.\n\nuv 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\u2019s installation prefix on uninstall.\n\nuv 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.\n\nStandards-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.\n\nAbsolute paths in RECORD files are not allowed by the specification and, when present, uv always treats them as rooted in the wheel\u2019s installation prefix. Absolute paths cannot be used to delete arbitrary files.\n\nOnly files can be deleted, attempts to delete a directory via an invalid RECORD entry will fail.\n\n## Patches\n\nVersions [0.11.6](https://github.com/astral-sh/uv/releases/tag/0.11.6) and newer of uv address the validation gap above, by [removing invalid entries from RECORD files on wheel installation](https://github.com/astral-sh/uv/pull/18943) and [ignoring RECORD paths that would escape the installation prefix on uninstall](https://github.com/astral-sh/uv/pull/18942).\n\n## Workarounds\n\nUsers are advised to upgrade to 0.11.6 or newer to address this advisory.\n\nUsers should experience no breaking changes as a result of the patch above.",
  "id": "GHSA-pjjw-68hj-v9mw",
  "modified": "2026-04-10T19:39:15Z",
  "published": "2026-04-10T19:39:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/astral-sh/uv/security/advisories/GHSA-pjjw-68hj-v9mw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/astral-sh/uv/pull/18942"
    },
    {
      "type": "WEB",
      "url": "https://github.com/astral-sh/uv/pull/18943"
    },
    {
      "type": "WEB",
      "url": "https://github.com/astral-sh/uv/commit/7983c7a5bef236fd8a04580fcedae7bd5bde4cdb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/astral-sh/uv/commit/a0e461ac44851f9a0f6e8974733e77d46f7a9ea9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/astral-sh/uv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/astral-sh/uv/releases/tag/0.11.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "uv vulnerable to arbitrary file deletion through RECORD entries"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…