Issue Summary Due to a flaw in pipenv's parsing of requirements files, an attacker can insert a specially crafted string inside a comment anywhere within a requirements.txt file, which will cause victims who use pipenv to install the requirements file (e.g. with "pipenv install -r requirements.txt") to download dependencies from a package index server controlled by the attacker. By embedding malicious code in packages served from their malicious index server, the attacker can trigger arbitrary remote code execution (RCE) on the victims' systems.

Impact The impact of successful exploitation is severe/critical.

If an attacker is able to hide a malicious --index-url option in a requirements file that a victim installs with pipenv, the attacker can embed arbitrary malicious code in packages served from their malicious index server that will be executed on the victim's host during installation (remote code execution/RCE). Exploitation using this technique would be relatively simple to achieve for an attacker with basic knowledge of Python, as the attacker can simply build a source distribution for any of the packages specified in the requirements file, and embed arbitrary malicious code in the setup.py file. When pip installs from a source distribution, any code in the setup.py is executed by the install process.

Basic attacks might use the initial RCE triggered when a victim installs the attacker's malicious package to steal credentials from the victim's host, leach the host's resources to mine cryptocurrency, or install exploit kits or other malware. More sophisticated attackers may use more advanced techniques to persist access to the victim's host, hide or remove evidence of their attack by deleting references to the malicious index server in the Pipfile and Pipfile.lock generated by pipenv or other potential indicators of compromise. Highly sophisticated attackers could attempt to pivot to additional targets from the initial compromised host, and might leverage any exposed credentials in the compromised host environment or implicit authorization granted to the host to gain privileged access to other systems or resources, such as source repositories or package registries.

Likelihood The overall likelihood of exploitation is low to moderate depending on a range of factors.

The primary hurdle to successful exploitation of this vulnerability depends on an attacker's ability to surreptitiously insert a specially crafted string into a requirements.txt file which will be installed by a victim (or victims). Unfortunately, because the attacker can insert this string into a comment, the attacker's ability to evade suspicion is greatly increased, and they may even be able to hide the initial payload in plain sight if a victim assumes that comments will be ignored by pipenv as expected.

In many common usage contexts — for example in environments where a requirements file is used to lock or "freeze" dependency versions for reproducible builds — requirements files can often become quite large, particularly when leveraging pip's integrity checking, which requires every dependency specified in the requirements file to includes hashes for all of its distribution files. In such cases, a malicious actor might mask an exploitation attempt by opening a pull request ostensibly to update or "bump" the project's dependencies to their latest versions, but surreptitiously insert a malicious —index-url option amidst the many other changes associated with updating the dependencies in a lock file. As these dependency updates often result in hundreds or even thousands of changes spread across the requirements file and are not easy to review manually, such an attack could be difficult to identify or prevent without tools or other mitigating controls.

Moreover, because the argparse module is used to parse the --index-url, --extra-index-url, and --trusted-host options, an attacker's ability to obfuscate their payload and hide their malicious intent is even more greatly enhanced, as the attacker may use abbreviated option names, which are supported by default with argparse. For example, an attacker can insert the string, "--t pypi.org" into a comment anywhere in the requirements file, which will automatically be expanded to "--trusted-host pypi.org" during processing by pipenv. This "--trusted-host pypi.org" option will disable SSL/TLS validation when pipenv attempts to connect to the default/official package index server (https://pypi.org/simple), and could allow a malicious index server to pose as the pipi.org index server in a man-in-the-middle attack.

Setting up the malicious index server to serve compromised package versions is relatively simple, even for a non-sophisticated attacker. As pip uses a simple directory format for serving packages, the malicious packages simply need to be placed in the correct folder structure and served using an HTTP server with autoindex enabled (e.g. python3 -m http.server).

Packaging up the exploit code into the malicious package versions would also be trivial for an attacker with basic knowledge of Python development, as the attacker can simply clone the source code for any of the packages specified in the requirements file, embed their malicious exploit code in the cloned package's setup.py file, and then build a source distribution of the package. When pip installs a package from a source distribution, any code in the setup.py is executed by the install process.

Additional Context & Details According to the requirements file format specification (https://pip.pypa.io/en/stable/reference/requirements-file-format/#comments), any lines which begin with a "#" character, and/or any text in a line following a whitespace and a "#" character, should be interpreted as a comment which will be removed/ignored during processing of the requirements file.

However, due to a flaw in pipenv's parsing of requirements files, an attacker can insert a specially crafted string inside a comment anywhere within a requirements.txt file, which will cause victims who use pipenv to install the requirements file (e.g. with "pipenv install -r requirements.txt") to download dependencies from a package index server controlled by the attacker. By embedding malicious code in packages served from their malicious index server, the attacker is then able to gain arbitrary remote code execution on the victims' systems.

The vulnerable requirements file parsing code is in the parseindexes(str: line) function of the pipenv.utils module:

https://github.com/pypa/pipenv/blob/cdde3f7bcee6bacba89538f73aba9401337be10c/pipenv/utils.py#L2061-L2078

This function is called iteratively on each line of a requirements file, and uses the argparse module to find and process --index-url, --extra-index-url, and --trusted-host options (and variations thereof). However, it does not ignore these options when they appear in comments, or validate that these options appear on their own lines as required by the requirements file specification (see: https://pip.pypa.io/en/stable/reference/requirements-file-format/#global-options). The options can also be abbreviated due to default behavior provided by the argparse.ArgumentParser object used to parse these options in the requirements file, so that --trusted-host and --t will be treated as equivalent by pipenv, for example.

For more information If you have any questions or comments about this advisory: Open an issue in https://github.com/pypa/pipenv/ Contact the pipenv maintainers: Dan Ryan Tzu-ping Chung Nate Prewitt Contact the contributor who discovered the issue and authored this report: Chris Passarello

It was reported [1],[2] that pip, a package installer for Python modules, would retrieve code to install in an insecure manner. When pip is used to install a module, that code is retrieved from the internet and then, in the presence of setup.py, is executed. If pip is used as root (e.g. "sudo pip install [module]"), then this code is executed with root permissions. Because pip does not do TLS certificate verification, or package verification, it is trivial for an attacker to perform a MitM attack and cause the user attempting to install a module to execute arbitrary code.

As of version 1.3, pip provides SSL certificate verification over HTTPS [3],[4].

[1] https://github.com/pypa/pip/issues/425 [2] http://www.reddit.com/r/Python/comments/17rfh7/warningdontusepipinanuntrustednetworka/ [3] https://github.com/pypa/pip/pull/791/files [4] http://www.pip-installer.org/en/latest/logic.html#ssl-certificate-verification

A flaw was found in python-pip. Installing remote packages is vulnerable to directory traversal via Content-Disposition header by a malicious server.

Upstream issue:

https://github.com/pypa/pip/issues/6413

DISPUTED An issue was discovered in pip (all versions) because it installs the version with the highest version number, even if the user had intended to obtain a private package from a private index. This only affects use of the --extra-index-url option, and exploitation requires that the package does not already exist in the public index (and thus the attacker can put the package there with an arbitrary version number). NOTE: it has been reported that this is intended functionality and the user is responsible for using --extra-index-url securely.

A vulnerability in the packageindex module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.

AIONLYREPORT package: python-pip-26.0.1-2.1.hum1 ------ Summary: Path Traversal via Malicious Entry Point Name in Wheel Metadata: A malicious wheel can use traversal or absolute entry-point names so pip writes generated script wrappers outside the intended scheme.scripts directory and overwrites files writable by the installing user. Requirements to exploit: An attacker must induce a victim to install a malicious wheel. The wheel must contain crafted consolescripts or guiscripts names with ../ traversal or absolute-path components in entrypoints.txt. The resulting overwrite is limited by the permissions of the installing user, but pip’s wheel-install flow reaches the vulnerable write path in normal operation and sets maker.clobber = True, so existing writable files are replaced when reachable. Component affected: github.com/pypa/pip - wheel installation flow in src/pip/internal/operations/install/wheel.py, vendored distlib script generation in src/pip/vendor/distlib/scripts.py, and entry-point parsing in src/pip/vendor/distlib/util.py Version affected: 26.0.1 (confirmed). Likely affects versions containing the same getentrypoints(...) -> getconsolescriptspecs(...) -> ScriptMaker.writescript(...) flow without target-directory enforcement. Patch available: no (a minimal proposed fix is included below; upstream release status unknown) Version fixed (if any already): unknown Upstream coordination: Not yet notified. This report is the initial triage. CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H AV:N - An attacker can distribute a malicious wheel through a package source or other network-delivered artifact. AC:L - Crafting traversal or absolute entry-point names in entrypoints.txt is straightforward. PR:N - The attacker needs no privileges on the victim system. UI:R - The victim must install the malicious wheel. S:U - Impact remains within the installing user's security scope. C:N - The primitive is attacker-controlled file overwrite, not direct data disclosure by default. I:H - Escaping scheme.scripts can overwrite writable files outside the intended install directory. A:H - Overwriting critical writable files can break applications or system behavior. Impact: Likely Important. This is a real arbitrary file overwrite/path traversal flaw in pip’s wheel installation flow. Exploitation requires a victim to install a malicious wheel, and the overwrite is limited to paths writable by the installing user. The written content is constrained to pip’s generated entry-point wrapper format rather than fully arbitrary bytes, which narrows the direct confidentiality impact, but escaping scheme.scripts can still severely affect integrity and availability and can lead to code execution when privileged or security-sensitive targets are overwritten. Embargo: yes Reason: No official fix is available, and the bug turns a malicious wheel into a write primitive outside the intended installation directory during a normal pip install flow. Public disclosure before a fix would make malicious package distribution campaigns easier, especially where wheels are installed with elevated privileges. Suggested public date: 15-Jul-2026 Acknowledgement: Aisle Research Steps to reproduce: 1. From the unpacked source tree, run: bash python - <<'PY' import os, tempfile, sys sys.path.insert(0, 'src') from pip.internal.operations.install.wheel import PipScriptMaker base = tempfile.mkdtemp(prefix='pip-script-test-') scripts = os.path.join(base, 'bin') os.makedirs(scripts, existok=True) absolutetarget = os.path.join(tempfile.gettempdir(), 'pip-owned') maker = PipScriptMaker(None, scripts) maker.clobber = True maker.variants = {''} maker.setmode = False for spec in [f'../../outside = os:path.join', f'{absolutetarget} = os:path.join']: files = maker.make(spec) print(spec, '->', files[0], '=>', os.path.abspath(files[0])) PY 2. Observe that the generated output path resolves outside scripts and that the file is written. 3. In a real installation context, a malicious wheel that places the same crafted names in entrypoints.txt reaches the same write sink during pip install and can overwrite attacker-chosen files writable by the installing user. Mitigation: Do not install untrusted wheels, especially in privileged contexts.

Avoid sudo pip install or other elevated wheel-install workflows until a fix is available.

Reject or inspect wheels whose entrypoints.txt contains path separators, .., or absolute entry-point names.

Vulnerability Details

pip already enforces path-traversal checks for wheel archive members extracted from the .whl, but generated entry-point wrappers are created later from metadata and do not go through that containment check. The vulnerable flow is: getentrypoints(distribution) reads consolescripts and guiscripts names from wheel metadata.

getconsolescriptspecs() formats those names into script specifications without sanitizing the name component.

PipScriptMaker.makemultiple() forwards the names to vendored distlib.

ScriptMaker.writescript() uses os.path.join(self.targetdir, name) and writes the generated wrapper without verifying that the resolved path stays inside targetdir.

Additional stage-5 verification confirmed that this is not limited to a direct PipScriptMaker API call: the full wheel-metadata path is reachable in both supported metadata backends, and absolute entry-point names are accepted in addition to ../ traversal. Relevant CWEs: CWE-22 (Path Traversal)

CWE-73 (External Control of File Name or Path)

Proposed Fix

A minimal defense-in-depth fix is to enforce that each generated script path remains inside targetdir before writing: diff diff --git a/src/pip/vendor/distlib/scripts.py b/src/pip/vendor/distlib/scripts.py @@ for name in names: outname = os.path.join(self.targetdir, name) + targetdir = os.path.abspath(self.targetdir) + outnameabs = os.path.abspath(outname) + if os.path.commonpath([targetdir, outnameabs]) != targetdir: + raise ValueError("Invalid script name %r: path traversal/absolute path" % name) if uselauncher: # pragma: no cover n, e = os.path.splitext(outname) Optionally, reject path separators and absolute paths earlier when parsing or validating entry-point names. ------ This report was generated using AI technology. Always review AI-generated content prior to use

pip 1.3 through 1.5.6 allows local users to cause a denial of service (prevention of package installation) by creating a /tmp/pip-build- file for another user.

pip before 1.3 allows local users to overwrite arbitrary files via a symlink attack on a file in the /tmp/pip-build temporary directory.

The mirroring support (-M, --use-mirrors) in Python Pip before 1.5 uses insecure DNS querying and authenticity checks which allows attackers to perform man-in-the-middle attacks.

A flaw was found in python-pip in the way it handled Unicode separators in git references. A remote attacker could possibly use this issue to install a different revision on a repository. The highest threat from this vulnerability is to data integrity.

pip absolute path traversal during download from malicious package indexes

Mercurial configuration injectable in repo revision when installing via pip

AIONLYREPORT package: python-pip-26.0.1-2.1.hum1 ------ Summary: Path Traversal via Malicious Entry Point Name in Wheel Metadata: A malicious wheel can use traversal or absolute entry-point names so pip writes generated script wrappers outside the intended scheme.scripts directory and overwrites files writable by the installing user. Requirements to exploit: An attacker must induce a victim to install a malicious wheel. The wheel must contain crafted consolescripts or guiscripts names with ../ traversal or absolute-path components in entrypoints.txt. The resulting overwrite is limited by the permissions of the installing user, but pip’s wheel-install flow reaches the vulnerable write path in normal operation and sets maker.clobber = True, so existing writable files are replaced when reachable. Component affected: github.com/pypa/pip - wheel installation flow in src/pip/internal/operations/install/wheel.py, vendored distlib script generation in src/pip/vendor/distlib/scripts.py, and entry-point parsing in src/pip/vendor/distlib/util.py Version affected: 26.0.1 (confirmed). Likely affects versions containing the same getentrypoints(...) -> getconsolescriptspecs(...) -> ScriptMaker.writescript(...) flow without target-directory enforcement. Patch available: no (a minimal proposed fix is included below; upstream release status unknown) Version fixed (if any already): unknown Upstream coordination: Not yet notified. This report is the initial triage. CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H AV:N - An attacker can distribute a malicious wheel through a package source or other network-delivered artifact. AC:L - Crafting traversal or absolute entry-point names in entrypoints.txt is straightforward. PR:N - The attacker needs no privileges on the victim system. UI:R - The victim must install the malicious wheel. S:U - Impact remains within the installing user's security scope. C:N - The primitive is attacker-controlled file overwrite, not direct data disclosure by default. I:H - Escaping scheme.scripts can overwrite writable files outside the intended install directory. A:H - Overwriting critical writable files can break applications or system behavior. Impact: Likely Important. This is a real arbitrary file overwrite/path traversal flaw in pip’s wheel installation flow. Exploitation requires a victim to install a malicious wheel, and the overwrite is limited to paths writable by the installing user. The written content is constrained to pip’s generated entry-point wrapper format rather than fully arbitrary bytes, which narrows the direct confidentiality impact, but escaping scheme.scripts can still severely affect integrity and availability and can lead to code execution when privileged or security-sensitive targets are overwritten. Embargo: yes Reason: No official fix is available, and the bug turns a malicious wheel into a write primitive outside the intended installation directory during a normal pip install flow. Public disclosure before a fix would make malicious package distribution campaigns easier, especially where wheels are installed with elevated privileges. Suggested public date: 15-Jul-2026 Acknowledgement: Aisle Research Steps to reproduce: 1. From the unpacked source tree, run: bash python - <<'PY' import os, tempfile, sys sys.path.insert(0, 'src') from pip.internal.operations.install.wheel import PipScriptMaker base = tempfile.mkdtemp(prefix='pip-script-test-') scripts = os.path.join(base, 'bin') os.makedirs(scripts, existok=True) absolutetarget = os.path.join(tempfile.gettempdir(), 'pip-owned') maker = PipScriptMaker(None, scripts) maker.clobber = True maker.variants = {''} maker.setmode = False for spec in [f'../../outside = os:path.join', f'{absolutetarget} = os:path.join']: files = maker.make(spec) print(spec, '->', files[0], '=>', os.path.abspath(files[0])) PY 2. Observe that the generated output path resolves outside scripts and that the file is written. 3. In a real installation context, a malicious wheel that places the same crafted names in entrypoints.txt reaches the same write sink during pip install and can overwrite attacker-chosen files writable by the installing user. Mitigation: Do not install untrusted wheels, especially in privileged contexts.

Avoid sudo pip install or other elevated wheel-install workflows until a fix is available.

Reject or inspect wheels whose entrypoints.txt contains path separators, .., or absolute entry-point names.

Vulnerability Details

pip already enforces path-traversal checks for wheel archive members extracted from the .whl, but generated entry-point wrappers are created later from metadata and do not go through that containment check. The vulnerable flow is: getentrypoints(distribution) reads consolescripts and guiscripts names from wheel metadata.

getconsolescriptspecs() formats those names into script specifications without sanitizing the name component.

PipScriptMaker.makemultiple() forwards the names to vendored distlib.

ScriptMaker.writescript() uses os.path.join(self.targetdir, name) and writes the generated wrapper without verifying that the resolved path stays inside targetdir.

Additional stage-5 verification confirmed that this is not limited to a direct PipScriptMaker API call: the full wheel-metadata path is reachable in both supported metadata backends, and absolute entry-point names are accepted in addition to ../ traversal. Relevant CWEs: CWE-22 (Path Traversal)

CWE-73 (External Control of File Name or Path)

Proposed Fix

A minimal defense-in-depth fix is to enforce that each generated script path remains inside targetdir before writing: diff diff --git a/src/pip/vendor/distlib/scripts.py b/src/pip/vendor/distlib/scripts.py @@ for name in names: outname = os.path.join(self.targetdir, name) + targetdir = os.path.abspath(self.targetdir) + outnameabs = os.path.abspath(outname) + if os.path.commonpath([targetdir, outnameabs]) != targetdir: + raise ValueError("Invalid script name %r: path traversal/absolute path" % name) if uselauncher: # pragma: no cover n, e = os.path.splitext(outname) Optionally, reject path separators and absolute paths earlier when parsing or validating entry-point names. ------ This report was generated using AI technology. Always review AI-generated content prior to use