GHSA-4gg8-gxpx-9rph

What it actually does

The vulnerability is a path traversal / arbitrary file write flaw in uv’s handling of Python package entry point names. When uv installs a package, it may generate executable wrapper files for declared entry points, such as console scripts. A malicious package can define an entry point name containing path separators or traversal sequences, causing uv versions before 0.11.15 to write generated files outside the intended scripts directory. Depending on the install context and filesystem permissions, this can overwrite or create files in unintended locations, potentially enabling persistence, build compromise, or code execution if the written file is later executed or loaded by another process.

Why it matters to the business

Organizations using uv to install Python dependencies may be exposed if developers, CI/CD jobs, build systems, or automation install an untrusted or compromised package. The most likely business risk is software supply-chain compromise: a malicious dependency could write files outside the expected virtual environment or project directory, potentially altering build artifacts, developer workstations, or automation environments. This issue is not currently listed in CISA KEV, has no reported exploit maturity in the provided data, and has been public for 73 days, so remediation should be prioritized for build and dependency-management environments rather than treated as an active mass-exploitation emergency.

How an attack unfolds

An attacker publishes or compromises a Python package and adds a malicious entry point name that includes traversal characters such as ../ or platform-specific path separators. A victim then installs that package using a vulnerable uv version. During installation, uv processes the package metadata and attempts to create the script wrapper for the entry point. Because the entry point name is not safely constrained to the scripts directory, uv writes a file to an attacker-influenced path outside the expected destination. The attacker’s practical outcome depends on where the file can be written: in lower-privilege contexts this may affect project or user-writable files; in CI, build, container, or privileged install contexts it may tamper with generated artifacts, startup scripts, configuration files, or other files that later cause attacker-controlled code to run.

How to fix it

Upgrade uv to version 0.11.15 or later everywhere it is used, including developer workstations, CI/CD runners, build containers, base images, dependency update bots, and release automation. Treat uv as part of the build toolchain, not just an application dependency. Rebuild container images and CI runner images that bake in uv. Re-run dependency installation after upgrading if there is concern that prior installs may have written unexpected files. As defense in depth, install dependencies only from trusted indexes, require lockfiles and hashes where feasible, restrict write permissions in build environments, run dependency installation as a non-privileged user, and review newly added or unusual Python package entry points before accepting dependency changes.

How to confirm the fix worked

Confirm that all uv installations report version 0.11.15 or later using `uv --version`. Check CI images, Dockerfiles, build scripts, package manager bootstrap scripts, and developer setup documentation for pinned uv versions older than 0.11.15. Validate that package installation with uv creates entry point wrappers only inside the expected virtual environment scripts directory, such as `.venv/bin/` on Unix-like systems or `.venv\Scripts\` on Windows. Audit installed package metadata for entry point names containing path separators, absolute paths, or traversal sequences. If old uv versions were used with untrusted dependencies, compare the filesystem against a clean build to identify unexpected files created or modified during dependency installation.

Typical attack path

1. Identify organizations or projects that use uv versions earlier than 0.11.15 for Python dependency installation.
2. Create or compromise a Python package that declares an entry point name containing path traversal or path separator characters.
3. Get the target to install the package through normal dependency workflows, dependency confusion, typosquatting, compromised maintainer credentials, or a poisoned lockfile.
4. During installation, rely on vulnerable uv behavior to generate an entry point wrapper at an unintended filesystem path.
5. Use the arbitrary file write to overwrite or plant a file that influences later execution, build output, developer tooling, startup behavior, or application packaging.
6. Wait for a user, CI job, test runner, shell, service, or deployment process to execute or consume the planted file.

How to detect it

Look for evidence of malicious or malformed Python package entry points and unexpected file creation during dependency installation. Relevant sources include CI/CD job logs, developer build logs, package installation logs, shell history, container build output, filesystem audit logs, endpoint detection telemetry, and file integrity monitoring. Search installed wheels and site-packages directories for `*.dist-info/entry_points.txt` files where entry point names contain traversal sequences, path separators, absolute Unix paths, Windows drive paths, or UNC paths. Review file creation events around the time `uv sync`, `uv pip install`, `uv add`, or related install commands ran, especially files written outside `.venv/bin`, `.venv/Scripts`, project-local build directories, or expected cache locations. Investigate any package installed shortly before unexpected executable scripts, configuration files, shell profiles, startup files, or CI artifacts appeared. Because no specific active exploitation or threat actor is provided, detection should focus on anomalous package metadata and filesystem writes rather than known campaign infrastructure.

• *.dist-info/entry_points.txt
• ../
• ..\
• [console_scripts]
• [gui_scripts]
• uv pip install
• uv sync
• uv add
• /etc/cron.d/
• /etc/profile.d/
• ~/.bashrc
• ~/.zshrc
• ~/.profile
• .github/workflows/
• C:\\Users\\Public\\
• C:\\ProgramData\\
• %APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup
• entry point name contains path separator
• entry point name contains traversal

What your security team should do

• Inventory uv usage across repositories, CI/CD pipelines, build images, developer bootstrap scripts, and release automation.
• Upgrade uv to 0.11.15 or later and rebuild any base images or runner images that include vulnerable versions.
• Prioritize remediation in environments that install third-party Python packages automatically or from public package indexes.
• Review recent dependency additions and lockfile changes for unfamiliar, typosquatted, or newly published packages.
• Search package metadata for suspicious entry point names containing `../`, `..\`, `/`, `\`, absolute paths, or drive-letter paths.
• Run dependency installation in isolated, non-privileged build environments with limited filesystem write access.
• Use dependency pinning, hash verification, package provenance controls, and trusted internal mirrors where practical.
• If suspicious packages or entry point metadata are found, perform forensic review of files modified during installation and rotate credentials available to the affected build environment.