A malicious or compromised package can make Composer change the permissions of a file outside the package's own folder, and register a vendor/bin command that points at it. A file that only its owner could read can end up readable and runnable by anyone on the machine.

This gets around the earlier fix for GHSA-gjfg-22fp-rrxx, which only blocked .. in a package's declared binaries. The Composer advisory says it isn't remote code execution, and the attacker can't read your data directly. The risk is mainly on shared or multi-user hosts.

Who is affected

You need a malicious or compromised package somewhere in your dependencies, including indirect ones. Then either of these exposes you:

  • The package ships a binary as a symbolic link (a pointer to another file) that leads outside its folder. A normal install or update is enough.
  • Your vendor/composer/installed.json declares a binary path outside the package's folder. That only happens when your vendor folder came from somewhere else, such as a shared CI cache or an earlier container build stage.

Composer says the most likely case is a build or deploy step that reuses a vendor folder made elsewhere.

What to do

Update composer/composer to 2.10.3. If you stay on 2.2 or older, update to 2.2.30. Composer says upgrading is the only complete fix. The fix checks that each binary stays inside its package's folder.

Reported by DavidCarliez, manus-use and arpitjain099.