GHSA-gjfg-22fp-rrxx

## 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.