CVE-2024-35242

What it actually does

Command injection via specially crafted git/hg branch names during composer install when the working directory is an untrusted repository clone.

Why it matters to the business

Attackers can execute arbitrary commands on developer or CI systems that process untrusted PHP dependency repositories, potentially leading to code theft, supply-chain tampering, or full workstation compromise.

How an attack unfolds

An attacker publishes or tricks a victim into cloning a malicious git repository containing branch names that embed shell commands. When the victim runs composer install inside that repository, the unsanitized branch name is passed to a shell, executing attacker-controlled commands.

How to fix it

Upgrade composer/composer to version 2.2.24 (2.2 LTS) or 2.7.7. Workaround: avoid running composer install inside clones of untrusted repositories.

How to confirm the fix worked

Confirm the installed composer version is at least 2.2.24 or 2.7.7; test that branch names containing shell metacharacters no longer result in command execution.

Typical attack path

1. Create a git repository with branch names containing command-injection payloads
2. Trick a target into cloning the repository and running composer install inside it
3. Composer parses the malicious branch name and passes it to an underlying shell command
4. Arbitrary OS commands execute with the privileges of the composer process

How to detect it

Review shell history, CI logs, and process execution logs for composer invocations that coincide with unusual branch names or unexpected child processes spawned during install operations.

What your security team should do

• Immediately upgrade all Composer installations to 2.2.24 or 2.7.7
• Add repository-origin checks or sandboxing for composer install steps in CI/CD pipelines
• Scan existing codebases and logs for any prior execution of composer inside untrusted clones