CVE-2026-59944 is a medium-severity (CVSS 6.1) Path Traversal vulnerability in composer/composer. A fix is available for composer/composer — see the affected versions and patch details below.
Composer: CVE-2026-59946 fix bypass via symlinked package bin path
Exploitation Status
No confirmed exploitation observed yet
- 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-2026-59944.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-59944 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
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
Summary
A malicious or compromised Composer package could, when installed as a dependency, cause Composer to change the permissions of a file outside that package's own directory and to register a runnable vendor/bin command that points at that outside file. This is a path traversal and link following issue. It is not remote code execution, the attacker gains no ability to read or receive your data directly. The risk is that a file which was readable only by its owner, but modifiable by Composer, can be made world readable and executable, which is enough to expose its contents on a shared or multi tenant host. The earlier hardening from GHSA-gjfg-22fp-rrxx can be bypassed, since it only rejected literal .. path segments in a package's declared binaries, and was only applied in a single place during dependency resolution.
Am I affected?
You can be affected if a malicious or compromised package, including a transitive dependency, is installed in your project, and either of the following is true:
- The dependency package ships one of its declared binaries as a symbolic link that resolves to a location outside the package's own directory. Nothing beyond a normal install or update is required.
- Or, the recorded metadata of your installed dependencies (
vendor/composer/installed.json) declares a binary path that escapes the package's directory. Composer regenerates missing binaries from that recorded metadata at the end of an install, and uses this metadata for reinstalls of the same package. In both of these cases the validation applied during dependency resolution is skipped. This situation is only reachable when yourvendordirectory is not populated from the same install run, which performs validation. For example a vendor directory restored from a shared or untrusted CI cache, copied in from an earlier container build stage, carried over from a Composer older than 2.10.2 or 2.2.29, or writable by a lower trust build step, could contain such malicious data.
The most realistic way to get hit is a composer install in a build or deploy step that reuses a vendor directory produced elsewhere, since the permission change is applied silently and with the privileges of the user running Composer.
Patched versions
Composer now verifies that each declared binary resolves to a path inside the installing package's own directory before it touches the file, and skips any binary that resolves outside it with a warning. Update to the patched releases (2.10.3 and 2.2.30).
Workarounds
Upgrading is the only complete fix.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | composer/composer | ≥ 2.3.0&&< 2.10.3 | 2.10.3composer require composer/composer:^2.10.3 |
| 🐘Packagist | composer/composer | ≥ 1.0&&< 2.2.30 | 2.2.30composer require composer/composer:^2.2.30 |
Detection & 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.10.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-59944 is resolved across your whole dependency graph.
Workarounds
Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Ensure the integrity of Composer's `vendor` directory and associated metadata. Avoid restoring `vendor` directories from untrusted caches or allowing lower-trust processes to modify them. Implement strict access controls on Composer project directories and perform Composer operations in a trusted, isolated build environment to prevent the introduction of malicious symlinks or metadata. This operational control may require adjustments to existing CI/CD pipelines or build processes.Source: Red Hat security advisory for CVE-2026-59944 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Hardened Images | composer-main-2.10.3-1.hum1 | RHSA-2026:63151 |
Frequently Asked Questions
Is CVE-2026-59944 in your dependencies?
Find it across Packagist, including transitive dependencies.