Summary
A command injection vulnerability in virtualenv-generated POSIX launchers can allow shell command execution when an interpreter path contains spaces or results in an overly long shebang. An attacker who can influence an environment's destination may cause commands to run with the user's privileges when the user later executes an affected launcher.
A command injection vulnerability in virtualenv-generated POSIX launchers can allow shell command execution when an interpreter path contains spaces or results in an overly long shebang. An attacker who can influence an environment's destination may cause commands to run with the user's privileges when the user later executes an affected launcher.
Affected context
The issue occurs during POSIX console-script generation when virtualenv or pip passes an incompletely quoted interpreter path to distlib. If the resulting shebang is too long or contains a space, distlib may generate a /bin/sh wrapper whose double-quoted path can still interpret command substitutions or backticks. Environment creation and activation alone do not trigger the behavior; an affected launcher must later be executed.
The issue occurs during POSIX console-script generation when virtualenv or pip passes an incompletely quoted interpreter path to distlib. If the resulting shebang is too long or contains a space, distlib may generate a /bin/sh wrapper whose double-quoted path can still interpret command substitutions or backticks. Environment creation and activation alone do not trigger the behavior; an affected launcher must later be executed.
Exploit preconditions
- Attack surface: POSIX console-script launchers generated inside Python virtual environments
- Required access: Ability to influence the environment destination or interpreter path used during launcher generation
- Trigger point: Execution of a previously generated affected launcher by a user or automated process
- Why exploitation is possible: Shell wrapper generation preserves command-substitution behavior in an incompletely quoted interpreter path
- Additional condition: Existing launchers may remain affected after the package used to create them is changed, and later package installation activity may generate new affected launchers
- Attack surface: POSIX console-script launchers generated inside Python virtual environments
- Required access: Ability to influence the environment destination or interpreter path used during launcher generation
- Trigger point: Execution of a previously generated affected launcher by a user or automated process
- Why exploitation is possible: Shell wrapper generation preserves command-substitution behavior in an incompletely quoted interpreter path
- Additional condition: Existing launchers may remain affected after the package used to create them is changed, and later package installation activity may generate new affected launchers
Why this happens
The vulnerability results from treating an interpreter path as data while generating a shell script without fully preventing shell metacharacter interpretation. When distlib falls back to a /bin/sh wrapper, double quotes do not suppress command substitutions or backticks, allowing attacker-controlled path content to be interpreted by the shell. This maps to CWE-78: Improper Neutralization of Special Elements used in an OS Command, because data incorporated into a command-execution context is not safely escaped.
The vulnerability results from treating an interpreter path as data while generating a shell script without fully preventing shell metacharacter interpretation. When distlib falls back to a /bin/sh wrapper, double quotes do not suppress command substitutions or backticks, allowing attacker-controlled path content to be interpreted by the shell. This maps to CWE-78: Improper Neutralization of Special Elements used in an OS Command, because data incorporated into a command-execution context is not safely escaped.
Potential impact
- Arbitrary commands may execute with the privileges of the user running the launcher
- User credentials, source code, or environment secrets could be exposed
- Development or build environments could be modified
- Automated workflows may execute attacker-controlled actions
- Compromised environments could facilitate broader supply-chain or lateral attacks
- Arbitrary commands may execute with the privileges of the user running the launcher
- User credentials, source code, or environment secrets could be exposed
- Development or build environments could be modified
- Automated workflows may execute attacker-controlled actions
- Compromised environments could facilitate broader supply-chain or lateral attacks
General mitigation guidance
Mitigation generally focuses on preventing untrusted path data from entering shell command contexts and ensuring generated launchers use safe execution semantics.
Common defensive patterns include:
- Use maintained tooling that fully quotes interpreter paths or avoids shell wrappers
- Regenerate existing launchers after applying the relevant vendor remediation
- Treat environment destinations and interpreter paths as untrusted input
- Prefer direct process execution over shell-mediated command construction
- Restrict who can create or modify virtual-environment directories
- Run build and automation jobs with least privilege and isolated credentials
- Review package installation workflows so later pip activity cannot recreate unsafe launchers
- Avoid executing launchers from environment directories whose ownership or contents are not trusted
Mitigation generally focuses on preventing untrusted path data from entering shell command contexts and ensuring generated launchers use safe execution semantics.
Common defensive patterns include:
- Use maintained tooling that fully quotes interpreter paths or avoids shell wrappers
- Regenerate existing launchers after applying the relevant vendor remediation
- Treat environment destinations and interpreter paths as untrusted input
- Prefer direct process execution over shell-mediated command construction
- Restrict who can create or modify virtual-environment directories
- Run build and automation jobs with least privilege and isolated credentials
- Review package installation workflows so later pip activity cannot recreate unsafe launchers
- Avoid executing launchers from environment directories whose ownership or contents are not trusted
How teams detect issues like this
Organizations can look for this issue through:
- Static analysis of launcher-generation code for shell wrappers and incomplete quoting
- Code review checks for interpreter paths interpolated into shell scripts
- Repository and artifact scans for generated launchers containing command substitutions or backticks
- File-integrity monitoring for unexpected changes in virtual-environment
bindirectories - Policy enforcement requiring trusted ownership and controlled creation of environment directories
- CI checks that create environments using paths containing spaces and long interpreter paths, then inspect generated scripts
- Automated code-review or software-composition tools that flag vulnerable launcher-generation components
Organizations can look for this issue through:
- Static analysis of launcher-generation code for shell wrappers and incomplete quoting
- Code review checks for interpreter paths interpolated into shell scripts
- Repository and artifact scans for generated launchers containing command substitutions or backticks
- File-integrity monitoring for unexpected changes in virtual-environment
bindirectories - Policy enforcement requiring trusted ownership and controlled creation of environment directories
- CI checks that create environments using paths containing spaces and long interpreter paths, then inspect generated scripts
- Automated code-review or software-composition tools that flag vulnerable launcher-generation components
