Composer Path Traversal Flaw Lets Malicious Packages Expose Sensitive Files

Composer users are urged to update their software following the disclosure of a path-traversal vulnerability. This flaw could allow a malicious or compromised PHP package to change file permissions outside of its own installation directory.

The vulnerability is tracked as CVE-2026-59944 and GHSA-96h3-5x6v-m776, affecting Composer versions 2.3.0 through 2.10.2 and versions 1.0 through 2.2.29.

Composer Path Traversal Flaw

The issue has been resolved in Composer versions 2.10.3 and 2.2.30. GitHub rates the severity of this vulnerability as Moderate and assigns it a CVSS v3.1 vector of CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N, indicating that exploitation requires local installation or update actions but can result in significant confidentiality impacts.

The vulnerability arises in Composer’s handling of binaries declared by installed packages. A malicious dependency may provide a binary path that resolves outside the package’s intended directory by exploiting path traversal or symbolic-link behaviors.

During installation, Composer can change permissions on the specified binary and register it as a runnable command in `vendor/bin`.

Before the patch, an attacker could misuse this process to direct Composer to a file outside the dependency’s own directory, allowing Composer to make that external file readable and executable by other users, depending on the permissions set during installation.

While the vulnerability does not directly enable remote code execution or automatically allow an attacker to retrieve files from a victim’s environment, it could reveal the contents of sensitive files on shared servers, multi-tenant hosting environments, or build systems where other local users can access files made world-readable.

The advisory notes that this vulnerability can bypass an earlier hardening measure introduced for GHSA-gjfg-22fp-rrxx. Although the earlier mitigation rejected literal “..” segments in declared package binaries, validation occurred only at a single point in the dependency resolution process.

Consequently, the protection could be bypassed when Composer rebuilt missing binaries from dependency metadata stored in `vendor/composer/installed.json` or when it followed a symbolic link that resolved to a path outside the package directory.

This issue is especially concerning when a project reuses a `vendor` directory that was not generated during the current trusted installation.

For example, this could include vendor directories restored from shared or untrusted CI caches, copied from a previous container build stage, inherited from an older Composer release, or modified by a lower-trust build process.

A realistic attack scenario involves a build or deployment pipeline running `composer install` against a reused `vendor` directory that contains tampered metadata or a malicious symlink.

Composer silently changes permissions using the privileges of the account executing the command. This means that a CI runner, deployment account, or shared hosting user could unintentionally alter access controls on files accessible via the crafted binary declaration.

The advisory connects the problem to CWE-22 (improper limitation of a pathname), CWE-59 (improper link resolution), and CWE-732 (incorrect permission assignment for a critical resource).

Composer now verifies that every declared binary resolves within the package being installed before modifying the target file. If a binary resolves outside that directory, Composer skips it and generates a warning.

Organizations are strongly advised to upgrade to Composer versions 2.10.3 or 2.2.30 immediately, as upgrading is the only complete solution to this issue.

Teams should also avoid restoring untrusted vendor directories, isolate CI caches by project and trust level, and regenerate dependencies from trusted lockfiles during production builds.

Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC