GHSA-jhfp-4ppm-crmm: 
PHP 취약점 분석 및 완화

Summary

A crafted composer.lock or vendor/composer/installed.json could cause Composer to run an arbitrary system command while resolving downloads during composer install or composer update. This is data-driven arbitrary command execution: it does not require a malicious package to be installed or any package code to run, only the ability to influence those two files, and the command runs before any checksum or integrity check. It is not a flaw in how trusted package code executes.

Am I affected?

You are affected if all of the following hold:

• You run Composer 2.10.0 through 2.11.1.
• You run composer install or composer update against a composer.lock or vendor/composer/installed.json whose contents an attacker could influence. Realistic ways that file becomes attacker-influenced include a pull request that only edits composer.lock, a shared or scaffolded project template that ships a lock file, a compromised dependency-update bot, or a CI cache that restores a poisoned lock or installed file. You are plainly not affected if nothing untrusted can modify your lock or installed-packages files, or if you are on the 2.2 LTS line (or any release before 2.10.0), which never had the affected option handling. The single most realistic way to get hit: automated CI that checks out a branch and runs composer install without a human reviewing the lock-file change. --no-scripts and --no-plugins do not prevent it.

Patched versions

Fixed in 2.11.2. The fix makes Composer ignore these download-time callback options when they come from the lock or installed-packages file, and only honor them when they are set programmatically.

Workarounds

The only complete fix is upgrading. To reduce risk until then, do not run composer install/update on lock or installed files from untrusted sources (unreviewed pull requests outside of CI running sandboxed, third-party templates, shared caches).