Composer 2.11.0 and 2.2.31 Patch Path Traversal and Token Leak Vulnerabilities
Do Son 
TL;DR
Maintainers of the PHP dependency manager disclosed two Composer vulnerabilities on October 29, 2026. These security flaws enable arbitrary local file deletion or overwriting during package installation. Moreover, they expose private repository API tokens inside lock files. Developers and build engineers must upgrade to Composer 2.11.0 or 2.2.31 (LTS) immediately.
Why It Matters
Composer is the foundational dependency manager for the PHP ecosystem, handling billions of monthly package installations via Packagist and over 29,000 stars on GitHub. While exact counts of vulnerable CI/CD pipelines and private repositories are not specified in the advisories, automated build workflows rely heavily on cached dependencies and lock files.
Leaving these Composer vulnerabilities unpatched puts continuous integration runners at risk of filesystem tampering. Also, it leaks sensitive authentication tokens into version control history. Currently, no public proof-of-concept exploit code has been published, and no active exploitation in the wild has been confirmed.
How the Attack Works
The two flaws target local package metadata validation and lock file generation during dependency resolution.
Path Traversal via Installed Package Metadata
First, the security advisory details a high-severity path traversal flaw (CVSS 7.1, CWE-22) reported by researcher euriconicacio. While Composer already rejected malicious package names in composer.lock and remote repository metadata, it trusted package names recorded locally in vendor/composer/installed.json.
If an attacker modifies vendor/composer/installed.json to include a package name with .. path segments, running composer install deletes a directory outside the vendor/ folder. Furthermore, running composer reinstall writes the package’s files to that external path with the privileges of the user running Composer. This scenario primarily affects CI pipelines that restore the vendor/ directory from a shared cache writable by untrusted jobs, such as forked pull requests.
API Token Disclosure in Lock Files
Second, the security advisory addresses a medium-severity information disclosure bug (CVSS 5.3, CWE-200) reported by Saku0512. When a composer-type repository is configured with inline HTTP headers via options.http.header in a global config.json file, Composer copies those headers into composer.lock under transport-options for every downloaded package. When developers commit composer.lock to version control or publish it as a build artifact, any embedded API tokens or credentials are exposed to anyone who can read the lock file. Credentials stored in auth.json or the COMPOSER_AUTH environment variable are not affected.
Affected Versions
Both Composer vulnerabilities affect all releases from 1.0 before 2.2.31, and from 2.3.0 before 2.11.0. Patched versions 2.11.0 and 2.2.31 (LTS) are unaffected.
Patch and Mitigation Steps
The maintainers resolved both issues in Composer 2.11.0 and 2.2.31 (LTS) by enforcing strict package name validation on locally installed metadata. They also omitting repository HTTP headers from composer.lock. Because existing lock files retain previously written headers, developers must run composer update –lock after upgrading to strip them out. Furthermore, teams that shared affected lock files must search their Git history for header entries under transport-options. They must also revoke any exposed tokens and migrate inline credentials to auth.json.
Support Our Threat Intelligence
Find our vulnerability reports and weekly recaps helpful? Support our work today and unlock a 100% ad-free reading experience!
Buy Me a Coffee
