A newly disclosed vulnerability in Composer could allow malicious or compromised PHP packages to alter permissions on files located outside their intended installation directory, potentially exposing sensitive data on shared and multi-tenant systems.
Tracked as CVE-2026-59944, the flaw affects Composer versions 2.3.0 through 2.10.2 and versions 1.0 through 2.2.29. Composer has addressed the issue in versions 2.10.3 and 2.2.30.
The vulnerability was rated Moderate and carries a CVSS v3.1 score based on the vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N. It is classified under CWE-22, or path traversal; CWE-59, improper link resolution; and CWE-732, incorrect permission assignment for critical resources.
Composer Path Traversal Flaw
Composer packages can declare executable binaries that are made available through the vendor/bin directory. A malicious package could provide a binary path that escapes its package directory or use a symbolic link resolving to a file outside that directory.
During installation, Composer may change permissions on the target file and create a runnable vendor/bin command pointing to it. If the external target file is normally readable only by its owner but remains modifiable by the Composer process, the flaw could make it world-readable and executable.
This creates a confidentiality risk, as other users on a shared host could read a previously restricted file. The issue does not, by itself, enable remote code execution or give an attacker a direct mechanism to retrieve data from an affected environment.
The advisory notes that the flaw bypasses protections introduced through the earlier GHSA-gjfg-22fp-rrxx fix. That hardening rejected literal .. path segments in declared package binaries, but only during a single dependency-resolution stage.
It did not fully validate paths after symbolic link resolution or across all binary restoration workflows. Organizations are most likely to be affected when a composer install operation reuses a vendor directory generated elsewhere.
This can occur when build systems restore dependencies from a shared or untrusted CI cache, copy them from an earlier container build stage, retain them from older Composer versions, or allow lower-trust build steps to write to the directory.
A separate attack path involves manipulated dependency metadata in vendor/composer/installed.json.
Composer can regenerate missing binaries from this metadata at the end of an installation or reuse it during reinstallation. In these cases, the validation applied during the original dependency-resolution process may be skipped.
The permission change occurs silently with the privileges of the account executing Composer, making CI/CD runners, deployment users, and shared hosting environments particularly important targets for review.
Mitigation
The patched Composer releases now validate that every declared binary resolves within the directory of the package currently being installed. Composer skips binaries resolving outside that boundary and displays a warning instead of modifying the external file.
Users should upgrade immediately to Composer 2.10.3 or 2.2.30, as upgrading is the only complete mitigation.
Security teams should also treat cached or inherited vendor directories as untrusted, rebuild dependencies in clean environments, protect CI cache write access, and investigate unexpected executable files or permission changes under application deployment paths.
Give your security team the visibility and context to investigate suspicious activity faster and contain threats before business impact grows. Strengthen Your Investigations with ANY.RUN
