GHSA-c968-33g3-wh7p: 
PHP vulnerability analysis and mitigation

Summary

Composer did not validate the package names recorded in vendor/composer/installed.json. A crafted entry whose name contains .. path segments made Composer delete a directory outside of vendor/ during composer install, and on composer reinstall also write the package's files there. Malicious names in composer.lock and in repository metadata were already rejected; only the locally recorded package list was trusted. This is arbitrary file deletion and file write with the privileges of the user running Composer. It is not exploitable remotely and cannot be triggered by publishing a package: the attacker has to be able to write to vendor/composer/installed.json on the machine running Composer.

Am I affected?

You can only be exposed to this if the vendor directory (specifically vendor/composer/installed.json) was not produced by a trusted Composer run on this machine. For example it was restored from a shared or untrusted CI cache, copied in from another container build stage or artifact, or is writable by a lower-trust step of your build. You are not affected if your vendor/ directory is only ever created and modified by Composer runs you trust, which is the case for most local development setups. The most realistic scenario is a CI pipeline that restores vendor/ from a cache that untrusted jobs (for example pull requests from forks) can also write to.

Patched versions

Composer now validates locally installed packages the same way it validates resolved and locked packages, and aborts before performing any operation if an invalid package is found. Fixed in Composer 2.11.0 and 2.2.31 (LTS).