GHSA-x82q-x274-r6pq: 
PHP 취약점 분석 및 완화

Summary

For projects that authenticate to a Composer repository using an inline HTTP header credential, a crafted composer.lock or vendor/composer/installed.json could cause that credential to be sent to a download mirror on an attacker-controlled host during composer install. This is an information disclosure issue limited to that repository credential. There is no code execution and no file modification.

Am I affected?

You are affected if all of the following hold:

• You run Composer 2.11.0, 2.11.1, or 2.2.31.
• You configure a Composer repository with an inline HTTP header that carries a secret, for example an Authorization bearer token or an API key set in the repository's options (common with Private Packagist and Satis-style setups).
• An attacker can influence your composer.lock or vendor/composer/installed.json, for example through a pull request that edits the lock file, a committed lock in a shared project, or a poisoned CI cache. When those hold, a crafted entry can add a preferred download mirror pointing at a host the attacker controls, and the repository credential is then sent to that host. You are plainly not affected if your repositories do not use an inline header credential, or if you are on a release that does not re-attach repository headers at load time (any version other than 2.11.0, 2.11.1, and 2.2.31).

Patched versions

Fixed in 2.11.2 and 2.2.32.

Workarounds

The only complete fix is upgrading.