GHSA-fm2w-xgf2-f9fh: 
PHP vulnerability analysis and mitigation

Summary

When a Composer repository is configured with inline HTTP headers (the options.http.header setting of a composer type repository), Composer copied those headers into composer.lock for every package downloaded from that repository. Such headers usually carry an API token or another credential, and composer.lock is usually committed to version control, so the credential could end up stored in places it was never meant to be. This is an information disclosure issue. It cannot be triggered by a malicious package or a remote party. Whether a credential was actually exposed depends on who can read the lock file.

Am I affected?

You are exposed if all of the following are true:

• You use a composer type repository with options.http.header set (the "inline custom headers" authentication method).
• That repository is defined outside the project's composer.json, typically in your global config.json (for example via composer config --global), so the project itself does not otherwise contain the credential.
• Package archives are downloaded from under that repository's URL, which is common for private Composer repositories.
• The generated composer.lock is shared with people or systems that should not have the credential, for example by committing it to a repository, publishing it as a build artifact or attaching it to a bug report. If the inline header is defined in the project's composer.json, it is also copied into composer.lock, but the credential is already in the committed composer.json, so the lock file adds no new exposure. You are not affected if your credentials are stored in auth.json or the COMPOSER_AUTH environment variable (http-basic, bearer, custom-headers, github-oauth and similar). Those were never written to composer.lock. The most likely way to be affected: a developer machine or CI worker has a private repository with a token header in its global config.json, runs composer update, and the resulting composer.lock is committed.

Patched versions

Composer no longer writes repository HTTP headers into composer.lock. When installing from a lock file, headers are taken from the currently configured repositories instead, so header based authentication keeps working. Fixed in Composer 2.11.0 and 2.2.31 (LTS). Existing lock files keep any headers they already contain until they are rewritten. After upgrading, run composer update --lock (or any update) to rewrite the lock file without them.

Workarounds

Upgrading is the fix. Until you can upgrade:

• If your repository supports it, store the credential in auth.json instead of an inline header, for example as bearer, http-basic, or custom-headers on Composer versions that support it.
• Check composer.lock for header entries under transport-options before committing or sharing it.

If you may have been affected

Search your repositories' history for composer.lock files containing header entries under transport-options. If a credential appears in a lock file that was shared, revoke and rotate it. Removing it from the latest commit does not remove it from the history.