- The Mess: A newly disclosed Composer flaw, CVE-2026-59944, lets a malicious PHP dependency abuse path traversal and symlinks to change permissions on files outside its own package directory. Composer released fixes after the earlier protection could be bypassed.
- The Damage: Sensitive files can become world-readable on shared servers, CI runners and multi-tenant build systems — potentially exposing SSH keys, configuration files or other secrets.
- The Fix: Upgrade Composer to 2.10.3 or 2.2.30, and rebuild reused or untrusted
vendordirectories from trusted sources.
Composer is supposed to install PHP dependencies.
It shouldn’t be changing the permissions of files it doesn’t own.
That’s exactly what CVE-2026-59944 can make happen.
And the interesting part is that this isn’t the first Composer bug of its kind.
It’s a bypass of an earlier fix.
The Dependency Gets Outside Its Box
Composer packages can define executable files through the bin field in composer.json.
During installation, Composer processes those entries and changes file permissions so the binaries can run.
The problem appears when a malicious package uses a path or symbolic link that resolves outside its own installation directory.
Instead of touching:
vendor/malicious-package/bin/tool
Composer can be tricked into touching another file on the system.
That’s the security boundary that breaks.
The File Doesn’t Have to Belong to Composer
The vulnerability doesn’t give an attacker direct remote code execution.
That’s important.
The attacker needs to get a malicious or compromised dependency into a project and have Composer process it.
But once that happens, the package can cause Composer to modify permissions on an existing file elsewhere on the machine.
Under common permissions, the file can become readable and executable by other users.
On a developer laptop, that may be limited.
On a shared build server?
Much more interesting.
CI/CD Is the Problem
Modern PHP projects don’t just run Composer on someone’s laptop.
They run it inside:
- CI runners
- deployment servers
- container builds
- shared hosting
- automated build systems
- multi-tenant infrastructure
Those environments often contain secrets.
SSH keys.
Environment files.
Cloud credentials.
Deployment tokens.
Private configuration.
A dependency shouldn’t be able to change the permissions on those files.
But that’s precisely the kind of situation CVE-2026-59944 can create.
The First Fix Wasn’t Enough
This is what makes the vulnerability more interesting than an ordinary path traversal.
Composer had already addressed a related issue, GHSA-gjfg-22fp-rrxx, which prevented literal .. path segments from escaping the package directory.
Attackers found another route.
Symbolic-link handling and previously generated dependency metadata could bypass the earlier protection.
Composer’s new fix validates where the binary actually resolves before changing permissions.
Security patches sometimes create exactly this kind of arms race.
Block the obvious path.
The filesystem has another one.
This Is Not an RCE
The internet loves turning every serious vulnerability into “remote code execution.”
Don’t.
CVE-2026-59944 is not a direct RCE.
Its published CVSS 3.1 vector is:
AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N
It requires local execution of the dependency installation process and user interaction.
The vulnerability changes permissions.
What happens afterward depends on what file was exposed and who can access it.
That distinction matters.
A Malicious Dependency Is Enough
The attack doesn’t necessarily require a package maintainer to be malicious.
A legitimate package could be compromised.
A dependency repository could be poisoned.
A transitive dependency could introduce the problem without the developer ever explicitly selecting it.
That makes software supply chains particularly interesting here.
The developer may trust:
Package A
while Composer installs:
A → B → C → malicious component
The vulnerable code doesn’t care which dependency introduced the malicious metadata.
It processes the package.
Composer 2.10.3 Closes the Hole
The vulnerability affects Composer versions:
- 2.3.0 through 2.10.2
- 1.0 through 2.2.29
The fixed releases are:
- 2.10.3
- 2.2.30 (gbhackers.com)
Composer’s official changelog specifically lists the fix for CVE-2026-59944 / GHSA-96h3-5x6v-m776.
If Composer is part of your deployment pipeline, this isn’t a version upgrade to postpone.
Don’t Trust Your Existing vendor Directory
Updating Composer is only half the job.
If a project has reused a vendor directory from an older build, shared cache or untrusted environment, rebuild it.
That means regenerating dependencies from a trusted composer.lock and avoiding blindly restoring old dependency directories.
Otherwise you’re trusting artifacts that may already contain the conditions required to trigger the vulnerability.
Bugstoday Opinion
CVE-2026-59944 isn’t spectacular.
No flashy RCE.
No ransomware gang.
No Internet-wide scanning campaign.
Just a dependency manager changing permissions on files it shouldn’t touch.
That’s exactly the kind of bug developers ignore until the affected file turns out to be an SSH key.
Bugstoday verdict: your PHP dependency shouldn’t be able to reach outside its own directory. If Composer is still below 2.10.3 or 2.2.30, stop trusting the dependency tree and update it.
Today’s Bugs. Tomorrow’s Breaches.
