Summary
A Composer package declares its executables in the bin field of its composer.json. When Composer installs a package, it processes each bin entry and changes the file mode of the corresponding file so it is executable.
If a bin entry contains .. path segments, it can resolve to a path outside the package's own install directory. A malicious package can use this to make Composer run chmod against a file that already exists elsewhere on the machine. The resulting mode is world-readable and world-executable (0755 under the common umask of 022). This happens when the package is installed, e.g. during composer install, composer update, and composer require. Any dependency can trigger it, including a transitive dependency several levels deep.
The vulnerability changes file permissions only, and does not read, modify, or execute the contents of the target file, and it is not remote code execution. The impact is to confidentiality: a file with deliberately restrictive permissions, such as a private key at mode 0600, can be made readable by other users on the same host.
Am I affected?
We reviewed packagist.org data and found no evidence that any published package exploited this vulnerability. If you install packages only from packagist.org, you are not affected by any known exploitation.
You are potentially affected if all of the following are true:
- Your Composer project depends, directly or transitively, on a package you do not fully trust.
- A file you rely on for its restrictive permissions already exists at a path the Composer process can write to. Examples include SSH private keys,
.env files, ~/.aws/credentials, and .netrc.
The most likely way to be affected is to add or update a dependency that is malicious or has been compromised, then run an install on a machine that holds sensitive, permission-restricted files.
Two points to note:
--no-scripts, --no-plugins, and an allow-plugins allow-list do not prevent this. The permission change happens during normal binary installation, outside the plugin and script trust model.- Impact scales with privilege: As a regular user, only files owned by that user can be affected, which typically means your own secrets becoming readable by other local users on a shared machine. As root (for example, a CI container with no non-root user, or
sudo composer install), any file on the system can be affected, including system credential stores.
Patched versions
The fix makes Composer reject any package whose binary entry contains a .. path segment. During install/update the operation aborts before any file permission is changed, and the same check now also applies when a package is published to Packagist.org, so such packages are refused upstream.
Fixed in 2.2.29 (2.2 LTS line) and 2.10.2 (current 2.x line). Composer 1.x is end of life and will not be patched. 1.x users should upgrade to a patched 2.x release.
Workarounds
Upgrading to a patched release is the only complete fix. There is no configuration option that disables the vulnerable behavior.
References
iliaal Reporter
Summary
A Composer package declares its executables in the
binfield of itscomposer.json. When Composer installs a package, it processes eachbinentry and changes the file mode of the corresponding file so it is executable.If a
binentry contains..path segments, it can resolve to a path outside the package's own install directory. A malicious package can use this to make Composer runchmodagainst a file that already exists elsewhere on the machine. The resulting mode is world-readable and world-executable (0755 under the common umask of 022). This happens when the package is installed, e.g. duringcomposer install,composer update, andcomposer require. Any dependency can trigger it, including a transitive dependency several levels deep.The vulnerability changes file permissions only, and does not read, modify, or execute the contents of the target file, and it is not remote code execution. The impact is to confidentiality: a file with deliberately restrictive permissions, such as a private key at mode 0600, can be made readable by other users on the same host.
Am I affected?
We reviewed packagist.org data and found no evidence that any published package exploited this vulnerability. If you install packages only from packagist.org, you are not affected by any known exploitation.
You are potentially affected if all of the following are true:
.envfiles,~/.aws/credentials, and.netrc.The most likely way to be affected is to add or update a dependency that is malicious or has been compromised, then run an install on a machine that holds sensitive, permission-restricted files.
Two points to note:
--no-scripts,--no-plugins, and anallow-pluginsallow-list do not prevent this. The permission change happens during normal binary installation, outside the plugin and script trust model.sudo composer install), any file on the system can be affected, including system credential stores.Patched versions
The fix makes Composer reject any package whose binary entry contains a
..path segment. During install/update the operation aborts before any file permission is changed, and the same check now also applies when a package is published to Packagist.org, so such packages are refused upstream.Fixed in 2.2.29 (2.2 LTS line) and 2.10.2 (current 2.x line). Composer 1.x is end of life and will not be patched. 1.x users should upgrade to a patched 2.x release.
Workarounds
Upgrading to a patched release is the only complete fix. There is no configuration option that disables the vulnerable behavior.
References