CVE-2024-24821 is a high-severity (CVSS 8.8) CWE-829 vulnerability in composer/composer. A fix is available for composer/composer — see the affected versions and patch details below.
Code execution and possible privilege escalation via compromised InstalledVersions.php or installed.php in Composer
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2024-24821.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
composer/composer🐘composer/composerReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Composer is a dependency Manager for the PHP language. In affected versions several files within the local working directory are included during the invocation of Composer and in the context of the executing user. As such, under certain conditions arbitrary code execution may lead to local privilege escalation, provide lateral user movement or malicious code execution when Composer is invoked within a directory with tampered files. All Composer CLI commands are affected, including composer.phar's self-update. The following scenarios are of high risk: Composer being run with sudo, Pipelines which may execute Composer on untrusted projects, Shared environments with developers who run Composer individually on the same project. This vulnerability has been addressed in versions 2.7.0 and 2.2.23. It is advised that the patched versions are applied at the earliest convenience. Where not possible, the following should be addressed: Remove all sudo composer privileges for all users to mitigate root privilege escalation, and avoid running Composer within an untrusted directory, or if needed, verify that the contents of vendor/composer/InstalledVersions.php and vendor/composer/installed.php do not include untrusted code. A reset can also be done on these files by the following:```sh
rm vendor/composer/installed.php vendor/composer/InstalledVersions.php
composer install --no-scripts --no-plugins
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | composer/composer | ≥ 2.0.0-alpha1&&< 2.2.23 | 2.2.23composer require composer/composer:^2.2.23 |
| 🐘Packagist | composer/composer | ≥ 2.3.0-rc1&&< 2.7.0 | 2.7.0composer require composer/composer:^2.7.0 |
Affected Products
composergetcomposerDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for composer/composer, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update composer/composer to 2.2.23 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2024-24821 is resolved across your whole dependency graph.
Workarounds
Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.
Frequently Asked Questions
Is CVE-2024-24821 in your dependencies?
Find it across Packagist, including transitive dependencies.