Summary
If the p4 Perforce CLI client is installed, a malicious dependency package from a package repository allowing arbitrary perforce source URLs (packagist.org is safe) could execute arbitrary commands when running composer install or composer update. Composer passed a package's Perforce source address to the p4 CLI client without validating it. The p4 CLI client accepts addresses that mean "run this local command" instead of "connect to this server". This is remote code execution with the privileges of the user or CI account running Composer.
Am I affected?
You are only affected if all of the following are true:
- The Perforce p4 command line client is installed and on the PATH of the machine running Composer. - An attacker can control a package metadata's source section with a perforce type. Packagist.org does not allow perforce source metadata, so you are only exploitable if you rely on another Composer repository (any custom composer-type repository, or an inline package repository entry), or a composer.lock file you obtained from somewhere you do not trust. - The package gets installed from source, either because it has no dist artifact or because source installs are selected (for example --prefer-source).
Plainly not affected: anyone without the p4 client installed, which is the large majority of Composer users. Perforce is an optional VCS integration. Also not affected: projects that only consume packages from Packagist.org, which does not allow Perforce source repositories and therefore cannot serve a package with a Perforce source address.
Most realistic way to get hit: a developer workstation or CI image that has Perforce tooling installed, pulling packages from a private or third party Composer repository that an attacker has compromised.
Patched versions
Composer now validates Perforce source addresses before handing them to the p4 client, and accepts only real network endpoints (an optional tcp/ssl transport with a host and port). Addresses that make the client spawn a local process are rejected, and the package fails validation on both update and install, before any p4 command runs. Fixed in Composer 2.10.3 and 2.2.30.
Note: If you legitimately use Perforce with an unusual P4PORT value that is not a plain host and port, Composer will now reject it.
Workarounds
Upgrading is the only complete fix.
Risk reduction short of upgrading:
- Remove the p4 client from the PATH of machines that run Composer but do not use Perforce. This fully blocks this specific attack, since the vulnerability depends on that client being present. - Restrict configured repositories to sources you control or trust, and treat lock files from untrusted sources as untrusted input.
Summary
A Composer package declares its executables in the bin field of its composer.json. When Composer installs a package, it processes each bin entry and changes the file mode of the corresponding file so it is executable.
If a bin entry contains .. path segments, it can resolve to a path outside the package's own install directory. A malicious package can use this to make Composer run chmod against a file that already exists elsewhere on the machine. The resulting mode is world-readable and world-executable (0755 under the common umask of 022). This happens when the package is installed, e.g. during composer install, composer update, and composer require. Any dependency can trigger it, including a transitive dependency several levels deep.
The vulnerability changes file permissions only, and does not read, modify, or execute the contents of the target file, and it is not remote code execution. The impact is to confidentiality: a file with deliberately restrictive permissions, such as a private key at mode 0600, can be made readable by other users on the same host.
Am I affected?
We reviewed packagist.org data and found no evidence that any published package exploited this vulnerability. If you install packages only from packagist.org, you are not affected by any known exploitation.
You are potentially affected if all of the following are true:
- Your Composer project depends, directly or transitively, on a package you do not fully trust. - A file you rely on for its restrictive permissions already exists at a path the Composer process can write to. Examples include SSH private keys, .env files, ~/.aws/credentials, and .netrc.
The most likely way to be affected is to add or update a dependency that is malicious or has been compromised, then run an install on a machine that holds sensitive, permission-restricted files.
Two points to note:
- --no-scripts, --no-plugins, and an allow-plugins allow-list do not prevent this. The permission change happens during normal binary installation, outside the plugin and script trust model. - Impact scales with privilege: As a regular user, only files owned by that user can be affected, which typically means your own secrets becoming readable by other local users on a shared machine. As root (for example, a CI container with no non-root user, or sudo composer install), any file on the system can be affected, including system credential stores.
Patched versions
The fix makes Composer reject any package whose binary entry contains a .. path segment. During install/update the operation aborts before any file permission is changed, and the same check now also applies when a package is published to Packagist.org, so such packages are refused upstream.
Fixed in 2.2.29 (2.2 LTS line) and 2.10.2 (current 2.x line). Composer 1.x is end of life and will not be patched. 1.x users should upgrade to a patched 2.x release.
Workarounds
Upgrading to a patched release is the only complete fix. There is no configuration option that disables the vulnerable behavior.
Summary
When Composer is run with -vvv (debug verbosity), it could print a credential that was embedded directly in a repository or package URL, but not as a password, to its debug output. Composer already masked the password portion of such URLs, but the username portion was shown in clear text. Because GitHub and several other services support placing an access token in the username position of a URL (for example https://[token]@github.com/owner/repo), a token used that way could end up written to the verbose log in full.
This is an information disclosure issue. The credential is only ever exposed to whoever can already read Composer's debug output.
Am I affected?
You are potentially affected only if all of the following apply:
- A credential is embedded inside a URL that Composer handles, e.g. in a repositories entry in composer.json, in a package dist/source URL - rather than being supplied through auth.json or the COMPOSERAUTH environment variable. - The secret sits in the username slot of that URL (e.g. https://TOKEN@host/…). A normal username:password@host pair where the username is an ordinary account name did not expose the password, that was already masked. - Composer is run with -vvv (debug verbosity), and that output is retained or shared somewhere others can read it: public CI build logs, output pasted into an issue or chat, archived terminal sessions, and so on.
If you keep credentials in auth.json or environment variables, or you never run Composer at debug verbosity, you were not exposed.
The most realistic exposure is the documented pattern of embedding a GitHub Personal Access Token in a URL's username position on a machine (often CI) that captures verbose output.
Patched versions
The username is now masked the same way the password already was, so an embedded token no longer appears in verbose output (a short, non-secret prefix may be shown to aid debugging, but never the full value).
Fixed in Composer 2.10.2 and the 2.2.29.
Workarounds
There is no configuration setting that prevents outputting credentials while keeping normal behavior.
If you cannot upgrade right away, you can reduce exposure by:
- Not running Composer with -vvv (debug verbosity) in environments where output is captured or shared. - Moving credentials out of URLs and into auth.json or COMPOSERAUTH. - Scrubbing existing CI/build logs that may already contain a leaked token.
Summary
A maliciously crafted package, published on an untrusted third party repository other than Packagist.org or Private Packagist, can cause Composer to write files outside the vendor/ directory and outside your project, with attacker-controlled content, during a normal install or update through using an invalid package name, which was not correctly validated by Composer.
This is an arbitrary file write that can be used to execute code outside the Composer project's context in which you expected the package code to execute (for example by writing shell startup files, SSH authorizedkeys, or a cron entry). It is a supply-chain issue: it requires a malicious or compromised package to be present in the dependency graph, it is not otherwise remotely exploitable against a machine.
The fix makes Composer validate every package produced by dependency resolution before anything is written to composer.lock or installed, and abort with a security error if a package name is not a valid vendor/package name.
Am I affected?
You may be affected if you install packages from an untrusted third party repository, which does not sufficiently validate package names. Packagist.org and Private Packagist are safe, as they validate package names correctly.
Patched versions
Fixed in 2.2.29 and 2.10.2. Composer 1.x is also affected and you should move to a safe 2.x release.
Workarounds
Do not use untrusted package repositories. If you have to, mirror them through an internal repository like Private Packagist.
Composer is a dependency manager for PHP. Versions 1.0 through 2.2.26 and 2.3 through 2.9.5 contain a command injection vulnerability in the Perforce::generateP4Command() method, which constructs shell commands by interpolating user-supplied Perforce connection parameters (port, user, client) without proper escaping. An attacker can inject arbitrary commands through these values in a malicious composer.json declaring a Perforce VCS repository, leading to command execution in the context of the user running Composer, even if Perforce is not installed. VCS repositories are only loaded from the root composer.json or the composer config directory, so this cannot be exploited through composer.json files of packages installed as dependencies. Users are at risk if they run Composer commands on untrusted projects with attacker-supplied composer.json files. This issue has been fixed in Composer 2.2.27 (2.2 LTS) and 2.9.6 (mainline).
Impact Attackers controlling remote sources that Composer downloads from might in some way inject ANSI control characters in the terminal output of various Composer commands, causing mangled output and potentially leading to confusion or DoS of the terminal application.
There is no proven exploit and this has thus a low severity but Composer still published a CVE as it has potential for abuse, and Composer wants to be on the safe side informing users that they should upgrade.
Patches 2.2.26 for 2.2 LTS or 2.9.3 for mainline.