Summary
Conda versions before 26.5.2 could process a malicious package metadata entry point as a filesystem path without confirming that it stayed within the target environment. An attacker supplying such a package may cause files to be written outside the environment or overwrite an existing entry point, with later execution potentially running attacker-controlled Python under the installing user's privileges.
Affected context
The vulnerability occurs during installation or environment transactions involving noarch:python packages whose info/link.json metadata contains an entry-point command. Risk is present when Conda constructs the wrapper path without canonicalizing it and without verifying that the resolved destination remains inside the environment's intended bin or Scripts directory. Writes outside the prefix additionally depend on the target parent directory already existing.
Exploit preconditions
- Attack surface: Conda package installation and environment transactions
- Required access: Ability to cause a victim to install or process a malicious package
- Trigger point: Creation of a Python entry-point wrapper from package metadata
- Required package condition: The package metadata supplies a command containing path separators, traversal segments, or an absolute path
- Why exploitation is possible: The derived path is joined to the environment prefix without enforcing a canonical path boundary
- Additional condition: Out-of-prefix writes generally require the destination's parent directory to exist
Why this happens
The underlying flaw is an insufficiently constrained path derived from untrusted package metadata. Conda interpolated the entry-point command into a destination path and joined it with the installation prefix, but did not canonicalize the result and verify that it remained within the designated executable directory. This is primarily CWE-22, Improper Limitation of a Pathname to a Restricted Directory, and is also related to CWE-73, External Control of File Name or Path.
Potential impact
- A malicious package may write an executable wrapper outside the intended environment directory
- An existing in-prefix entry point could be overwritten
- A later invocation of the overwritten entry point could execute attacker-controlled Python
- Files owned or writable by the installing user may be modified
- Package installation integrity and environment isolation could be weakened
General mitigation guidance
Mitigation generally focuses on treating package metadata as untrusted and
enforcing destination boundaries before any file is created.
Common defensive patterns include:
- Canonicalizing or normalizing the candidate destination before use
- Requiring the resolved path to remain beneath the intended bin or Scripts directory
- Rejecting absolute paths, traversal segments, and unexpected path separators in entry-point metadata
- Using secure path-joining helpers that enforce an allowed root
- Preventing replacement of unrelated existing files unless an explicit, validated ownership relationship exists
- Running package installation with least privilege and limiting writable filesystem scope
- Applying package trust, provenance, and repository policy controls
How teams detect issues like this
Detection approaches commonly include:
- Static analysis for path construction from package metadata without canonicalization or root containment checks
- Code review of entry-point generation, prefix joining, and file creation logic
- Tests using absolute paths, traversal segments, platform-specific separators, and symlinked directories
- Runtime auditing of package transactions that create or modify files outside the environment's executable directory
- Policy checks requiring validated package provenance and restricting installation from untrusted sources
- Automated security review tools that flag externally controlled filenames used in filesystem operations
