- Product: composer
- Vulnerabilities: 3 flaws (CVE-2026-59946, CVE-2026-59947, CVE-2026-59948)
- Highest severity: 7.0 (High · CVSSv3)
- Worst impact: Arbitrary file write outside vendor via malicious transitive package name
- Status: No confirmed exploitation yet
- Action: See vendor advisories
| CVE | CVSS | Type | Status |
|---|---|---|---|
| CVE-2026-59948 | 7.0 | CWE-22 | Not exploited |
| CVE-2026-59946 | 6.1 | CWE-22 | Not exploited |
| CVE-2026-59947 | 4.7 | CWE-532 | Not exploited |
TL;DR
PHP Composer, the main dependency manager for the language, patched three security flaws. The most serious, CVE-2026-59948, is an arbitrary file write rated CVSS 7.0. A malicious package can write files outside your project and run code outside the Composer project’s context. The fixes ship in Composer 2.10.2 and 2.2.29. The maintainers report no evidence of exploitation.
Why it matters
PHP Composer sits at the center of nearly every PHP project. So a bug in how it installs packages reaches a huge base of developers and CI systems. Two of these flaws are supply-chain issues. They only trigger when a malicious package enters your dependency graph. Still, that is exactly how modern attacks spread. Risk also climbs in CI containers that run installs as root. The Composer team published the full details in its GitHub security advisories.
How the attacks work
Each flaw takes a different path, so let me break them down.
CVE-2026-59948: arbitrary file write (CVSS 7.0)
This bug is a supply-chain issue. A malicious package from an untrusted repository can carry an invalid package name. Composer failed to validate that name during dependency resolution. As a result, an install or update could write files outside the vendor/ folder with attacker-controlled content. From there, an attacker can drop a shell startup file, an SSH authorized_keys entry, or a cron job. That is how a package can run code outside the Composer project’s context. Packagist.org and Private Packagist validate names, so they stay safe.
CVE-2026-59946: bin field path traversal (CVSS 6.1)
A package lists its executables in the bin field. Composer marks each one executable during install. If a bin entry hides .. segments, it can point outside the package directory. Then Composer runs chmod on a file that already exists elsewhere. The target becomes world-readable at mode 0755. A private key set to 0600 could suddenly be readable by other local users. Notably, –no-scripts and –no-plugins do not block this. Impact also scales with privilege, so a root install can touch any file on the host.
CVE-2026-59947: token leak to debug logs (CVSS 4.7)
Composer already masked passwords in URLs. Yet it printed the username in clear text at debug verbosity. Some services place an access token in the username slot, like https://TOKEN@github.com. So a GitHub token used that way could land in a verbose CI log in full. The risk is disclosure to anyone who can read that output.
Exploitation status
There are no confirmed attacks. The Composer team reviewed Packagist.org data for the path-traversal bug and found no package abusing it. Moreover, no public proof-of-concept has appeared for any of the three flaws.
Affected versions
All three flaws affect current 2.x releases before the patch. The file-write and path-traversal bugs also affect Composer 1.x, which is end of life. Those users should move to a patched 2.x build rather than wait for a backport.
Patch and mitigation
Update now to Composer 2.10.2 on the current line, or Composer 2.2.29 on the 2.2 LTS line. Run composer self-update to pull the fix. Until you patch, harden how PHP Composer pulls packages. Install only from trusted repositories such as Packagist. Also, keep credentials in auth.json or environment variables, not in URLs. Finally, avoid debug verbosity in places where logs are captured or shared, and scrub any CI logs that may already hold a leaked token.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.