Composer: GHSA-gjfg-22fp-rrxx fix bypass via symlinked package bin path

A malicious or compromised dependency can make Composer change permissions on a file outside that package and register a runnable vendor/bin command pointing to it. If Composer can modify an owner-only readable file, this could make it readable and executable by everyone, exposing its contents on a shared host. This can happen during a normal install or update through a symlinked package binary, or through malicious installed metadata in a reused vendor directory. It is not remote code execution and does not directly let the attacker read or receive your data.

Check composer/composer in composer.lock for versions >= 2.3.0 and < 2.10.3, or >= 1.0 and < 2.2.30. For an affected version, check dependencies, including transitive ones, for declared binaries that are symbolic links resolving outside their package directory. Also inspect vendor/composer/installed.json for declared binary paths escaping the package directory if vendor was populated elsewhere, such as from a shared or untrusted CI cache, an earlier container build stage, an older Composer run, or a lower trust build step. That metadata can be used when Composer regenerates missing binaries or reinstalls the same package.

Upgrading to 2.10.3 or 2.2.30 is the only complete fix.

Summary

A malicious or compromised Composer package could, when installed as a dependency, cause Composer to change the permissions of a file outside that package's own directory and to register a runnable vendor/bin command that points at that outside file. This is a path traversal and link following issue. It is not remote code execution, the attacker gains no ability to read or receive your data directly. The risk is that a file which was readable only by its owner, but modifiable by Composer, can be made world readable and executable, which is enough to expose its contents on a shared or multi tenant host. The earlier hardening from GHSA-gjfg-22fp-rrxx can be bypassed, since it only rejected literal .. path segments in a package's declared binaries, and was only applied in a single place during dependency resolution.

Am I affected?

You can be affected if a malicious or compromised package, including a transitive dependency, is installed in your project, and either of the following is true:

• The dependency package ships one of its declared binaries as a symbolic link that resolves to a location outside the package's own directory. Nothing beyond a normal install or update is required.
• Or, the recorded metadata of your installed dependencies (vendor/composer/installed.json) declares a binary path that escapes the package's directory. Composer regenerates missing binaries from that recorded metadata at the end of an install, and uses this metadata for reinstalls of the same package. In both of these cases the validation applied during dependency resolution is skipped. This situation is only reachable when your vendor directory is not populated from the same install run, which performs validation. For example a vendor directory restored from a shared or untrusted CI cache, copied in from an earlier container build stage, carried over from a Composer older than 2.10.2 or 2.2.29, or writable by a lower trust build step, could contain such malicious data.

The most realistic way to get hit is a composer install in a build or deploy step that reuses a vendor directory produced elsewhere, since the permission change is applied silently and with the privileges of the user running Composer.

Patched versions

Composer now verifies that each declared binary resolves to a path inside the installing package's own directory before it touches the file, and skips any binary that resolves outside it with a warning. Update to the patched releases (2.10.3 and 2.2.30).

Workarounds

Upgrading is the only complete fix.