GHSA-pjjw-68hj-v9mw — uv
Fix: astral-sh/uv#18942GHSA-pjjw-68hj-v9mw is a security vulnerability in uv. A fix is available for uv — see the affected versions and patch details below.
uv vulnerable to arbitrary file deletion through RECORD entries
Real-World Exposure
uvReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | uv | all versions | 0.11.6pip install --upgrade 'uv==0.11.6' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for uv, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update uv to 0.11.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pjjw-68hj-v9mw is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-pjjw-68hj-v9mw can be triaged on real exposure rather than presence alone.
Tailored to GHSA-pjjw-68hj-v9mw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-pjjw-68hj-v9mw in your dependencies?
O3 Security finds GHSA-pjjw-68hj-v9mw across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.