Composer 2.7.7 & Security Audit by Cure53 funded by Alpha-Omega

Today we’re releasing Composer 2.7.7 (PHP 7.2+) and 2.2.24 (LTS for use on PHP 5.3 to 7.1) to address two security vulnerabilities as well as a number of smaller security hardening measures, please update to the new versions immediately (e.g. with composer self-update ).

The problems detailed in this post were identified by security firm Cure53 as part of an audit performed over the last weeks on both Composer and packagist.org. This audit was funded by the Alpha-Omega project at the Linux Foundation, an initiative aiming to find and fix security vulnerabilities in open source code to improve global supply chain security.

We would like to thank both Alpha-Omega and Cure53 for their efforts to improve the security of the PHP ecosystem, and in particular Michael Winser and Mario Heiderich for making the audit happen. We will follow up with a more detailed report on all findings of the audit in another blog post at a later point, but wanted to immediately address the following two security issues.

The full changelog for Composer 2.7.7 is available on GitHub: https://github.com/composer/composer/releases/tag/2.7.7

CVE-2024-35241: Command injection via malicious git branch name 

The status, reinstall and remove commands could be made to execute an attacker’s code. To do so, a package under the attacker’s control needs to be present in the vendor directory as a git clone, so installed from source via git, rather than the default behavior of installing from “dist”, so typically a zip file. Due to lacking escaping of the branch names before passing the branch to a git diff command as part of the mentioned 3 composer commands, a specially crafted branch name can be used to execute code while these commands run.

Packagist.org and Private Packagist do not call the code paths that lead to this behavior, so no remote code execution was possible on our systems.

Thank you to Martin Haunschmid for discovering this vulnerability.

CVE-2024-35242: Multiple command injections via malicious git/hg branch names

Running composer install inside a checked out git/hg repository which has specially crafted branch names can lead to command injection. The code to work out the currently checked out Composer version based on the checked out branch name does not properly escape the branch names it considers and allows an attacker to execute code through them. This is a problem if you clone untrusted repositories directly that contain these branch names. Unlike the previous problem, it’s not exploitable from packages installed as dependencies.

Packagist.org and Private Packagist are not affected by this problem, so no remote code execution was possible on our systems as a result of this vulnerability.

Thank you to Maciej Piechota (haqpl) for discovering this vulnerability.

Conclusions

For PHP applications in general, these issues highlight the need for using a well researched library to encapsulate input escaping for running system processes and specifically shell commands based on user input in PHP. We recommend choosing an option allowing you to supply separate arguments/options as a PHP array instead of concatenating strings in your application. Current versions of the Symfony Process component do a great job at helping avoid these types of vulnerabilities.

We’re glad, that, to the best of our knowledge, the audit discovered these problems before they were used by anyone with malicious intent. This really highlights the value of regular security audits to search for potential flaws in software supply chain infrastructure like Composer and Packagist.