CVE-2024-35241

What it actually does

Command injection vulnerability allowing arbitrary code execution when Composer executes git commands on repositories containing specially crafted branch names during status, reinstall, or remove operations on source-installed packages.

Why it matters to the business

Attackers can gain remote code execution on developer workstations and build systems that manage PHP dependencies, potentially leading to supply-chain compromise, data theft, or deployment of malware into production software.

How an attack unfolds

An attacker publishes a malicious PHP package on a git repository with a branch name containing shell metacharacters. When a victim runs composer status, reinstall, or remove on a project depending on that package installed from source, Composer passes the branch name unsafely to a shell command, resulting in code execution.

How to fix it

Upgrade to Composer 2.2.24 or 2.7.7. As a workaround, configure preferred-install to dist or pass --prefer-dist to avoid source installations from git.

How to confirm the fix worked

Verify Composer version is at least 2.2.24 or 2.7.7; test by attempting to run the affected commands against a repository with a known-malicious branch name in a controlled environment; confirm that git operations no longer expand untrusted branch names into shell commands.

Typical attack path

1. Attacker creates a git repository with a package and a branch name embedding shell commands
2. Victim adds the malicious package as a dependency installed from source via git
3. Victim executes composer status, reinstall, or remove
4. Composer invokes git with the crafted branch name, triggering command injection
5. Arbitrary code executes under the privileges of the Composer process

How to detect it

Review Composer logs, git command history, and shell audit logs for unexpected branch names or shell metacharacters during status/reinstall/remove operations; look for processes spawned by Composer that perform unexpected network or file activity.

What your security team should do

• Immediately upgrade all Composer installations to 2.2.24 (LTS) or 2.7.7
• Enforce preferred-install: dist in composer.json or use --prefer-dist in CI pipelines
• Scan dependency manifests and lockfiles for any packages installed from git source
• Add Composer version checks to build pipelines and developer onboarding
• Monitor for new Composer releases given the package manager's central role in PHP ecosystems