Summary
setuptools: Windows path escape via namespace_packages.txt during legacy wheel installation Description
On Windows, attacker-controlled content in a wheel's.dist-info/namespace_packages.txt can cause setuptools' legacy wheel
installation path to create an __init__.py outside the requesteddestination_eggdir.
The attacker can influence the destination path, but not the contents of
the created file.
Details
Tested setuptools commit:
6ead555c5fb29bc57fe6105b1bffc163f56fd558
Relevant source:
setuptools/wheel.py
SHA-256:
359b7e0d5dd8c3135653abe08a8ed5dc0352eadfd7df22cb5e2b5303b7c3cafd
The relevant call path is:
Wheel(wheel_path).install_as_egg(destination)
→ _install_as_egg
→ _convert_metadata
→ _fix_namespace_packages
A wheel can provide attacker-controlled content in:
<distribution>.dist-info/namespace_packages.txt
The namespace value is eventually used approximately as:
mod_dir = os.path.join(destination_eggdir, *mod.split('.'))
mod_init = os.path.join(mod_dir, '__init__.py')
If mod is a Windows drive-qualified absolute path containing no dots,
mod.split('.') preserves it as a single component.
On Windows, os.path.join(destination_eggdir, absolute_component) discards
the original base directory and resolves to the attacker-supplied absolute
path.
The existing wheel filename and ZIP traversal checks do not validate this
metadata value before it is subsequently interpreted as a filesystem path.
```markdown
## PoC
The reproduction was performed entirely inside a disposable temporary
directory.
Layout:
```text
sandbox/
destination/
outside/
input/
canary.txt
A synthetic wheel was created containing:
demo_pkg-1.0.dist-info/namespace_packages.txt
whose content was the absolute path of:
sandbox\outside
The real acquired setuptools implementation was then invoked:
setuptools.wheel.Wheel(synthetic_wheel).install_as_egg(
sandbox_destination
)
The operation completed without exception.
Expected metadata was created under:
sandbox\destination\EGG-INFO
but setuptools also created:
sandbox\outside\__init__.py
The file did not exist before execution.
Its contents were:
__import__('pkg_resources').declare_namespace(__name__)
The unrelated canary remained byte-identical.
The sandbox was deleted after recording the evidence.
### Impact
A crafted wheel can cause setuptools to create a fixed-content
`__init__.py` outside the intended installation directory at a
filesystem path influenced by the wheel, with the permissions of the
process performing the installation.
The demonstrated reproduction required the target parent directory to
already exist.
Impact
Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-XMJ3-9GF7-H52W? GHSA-XMJ3-9GF7-H52W is a low-severity path traversal vulnerability in setuptools (pip), affecting versions >= 38.2.2, < 84.1.0. It is fixed in 84.1.0. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
- Which versions of setuptools are affected by GHSA-XMJ3-9GF7-H52W? setuptools (pip) versions >= 38.2.2, < 84.1.0 is affected.
- Is there a fix for GHSA-XMJ3-9GF7-H52W? Yes. GHSA-XMJ3-9GF7-H52W is fixed in 84.1.0. Upgrade to this version or later.
- Is GHSA-XMJ3-9GF7-H52W exploitable, and should I be worried? Whether GHSA-XMJ3-9GF7-H52W is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-XMJ3-9GF7-H52W is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-XMJ3-9GF7-H52W? Upgrade
setuptoolsto 84.1.0 or later.