Impact The Perforce::generateP4Command() method constructed shell commands by interpolating user-supplied Perforce connection parameters (port, user, client) without proper escaping. An attacker controlling a repository configuration in a malicious composer.json declaring a Perforce VCS repository could inject arbitrary commands through these values, leading to command execution in the context of the user running Composer. Composer would execute these injected commands even if Perforce is not installed.

VCS repositories are only loaded from the root composer.json file located in the directory you execute Composer commands in and from the composer config directory (e.g. ~/.config/composer/composer.json). So this vulnerability cannot be exploited through composer.json files of packages installed as dependencies.

You are at risk of command execution if you run Composer commands on untrusted projects with attacker supplied composer.json files, regardless of whether you or any of your dependencies use Perforce.

Patches Fixed in Composer 2.2.27 (2.2 LTS) and 2.9.6 (mainline)

Workarounds - Carefully inspect composer.json files before running Composer on them. Verify that Perforce-related fields contain valid values. - Only run Composer commands on projects from trusted sources.

Impact The Perforce::syncCodeBase() method appended the $sourceReference parameter to a shell command without proper escaping, allowing an attacker to inject arbitrary commands through a crafted source reference containing shell metacharacters. Further as in GHSA-wg36-wvj6-r67p / CVE-2026-40176 the Perforce::generateP4Command() method constructed shell commands by interpolating user-supplied Perforce connection parameters (port, user, client) without proper escaping from the source url field. Composer would execute these injected commands even if Perforce is not installed.

The source reference and url are provided as part of package metadata. Any Composer package repository can serve package metadata declaring perforce as a source type with a malicious source reference or source url. This means the vulnerability can be exploited through any package served by a compromised or malicious Composer repository. An attack does not require Perforce to be installed on the client, as Composer will attempt to execute the constructed command regardless.

This vulnerability is exploitable when installing or updating dependencies from source (--prefer-source, default when installing dev prefixed versions), even if you do not use Perforce.

Patches Fixed in Composer 2.2.27 (2.2 LTS) and 2.9.6 (mainline)

Note, the fix for the source url in the Perforce::generateP4Command() was addressed as part of the patches for GHSA-wg36-wvj6-r67p / CVE-2026-40176 in the same versions.

Workarounds

- Avoid installing dependencies from source by using --prefer-dist or the preferred-install: dist config setting. - Only use trusted Composer repositories.

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.

Impact

Several files within the local working directory are included during the invocation of Composer and in the context of the executing user.

As such, under certain conditions arbitrary code execution may lead to local privilege escalation, provide lateral user movement or malicious code execution when Composer is invoked within a directory with tampered files.

All Composer CLI commands are affected, including composer.phar's self-update.

The following are of high risk:

- Composer being run with sudo. - Pipelines which may execute Composer on untrusted projects. - Shared environments with developers who run Composer individually on the same project.

Patches

2.7.0, 2.2.23

Workarounds

- It is advised that the patched versions are applied at the earliest convenience.

Where not possible, the following should be addressed: - Remove all sudo composer privileges for all users to mitigate root privilege escalation. - Avoid running Composer within an untrusted directory, or if needed, verify that the contents of vendor/composer/InstalledVersions.php and vendor/composer/installed.php do not include untrusted code.

A reset can also be done on these files by the following:

sh rm vendor/composer/installed.php vendor/composer/InstalledVersions.php composer install --no-scripts --no-plugins

Impact

Users publishing a composer.phar to a public web-accessible server where the composer.phar can be executed as a php file may be impacted if PHP also has registerargcargv enabled in php.ini.

Patches

2.6.4, 2.2.22 and 1.10.27 patch this vulnerability.

Workarounds

Make sure registerargcargv is disabled in php.ini, and avoid publishing composer.phar to the web as this really should not happen.

Composer is a dependency manager for the PHP programming language. Integrators using Composer code to call VcsDriver::getFileContent can have a code injection vulnerability if the user can control the $file or $identifier argument. This leads to a vulnerability on packagist.org for example where the composer.json's readme field can be used as a vector for injecting parameters into hg/Mercurial via the $file argument, or git via the $identifier argument if you allow arbitrary data there (Packagist does not, but maybe other integrators do). Composer itself should not be affected by the vulnerability as it does not call getFileContent with arbitrary data into $file/$identifier. To the best of our knowledge this was not abused, and the vulnerability has been patched on packagist.org and Private Packagist within a day of the vulnerability report.

Impact Windows users running Composer to install untrusted dependencies are affected and should definitely upgrade for safety. Other OSs and WSL are not affected.

Patches 1.10.23 and 2.1.9 fix the issue

Workarounds None

Composer is a dependency manager for PHP. URLs for Mercurial repositories in the root composer.json and package source download URLs are not sanitized correctly. Specifically crafted URL values allow code to be executed in the HgDriver if hg/Mercurial is installed on the system. The impact to Composer users directly is limited as the composer.json file is typically under their own control and source download URLs can only be supplied by third party Composer repositories they explicitly trust to download and execute source code from, e.g. Composer plugins. The main impact is to services passing user input to Composer, including Packagist.org and Private Packagist. This allowed users to trigger remote code execution. The vulnerability has been patched on Packagist.org and Private Packagist within 12h of receiving the initial vulnerability report and based on a review of logs, to the best of our knowledge, was not abused by anyone. Other services/tools using VcsRepository/VcsDriver or derivatives may also be vulnerable and should upgrade their composer/composer dependency immediately. Versions 1.10.22 and 2.0.13 include patches for this issue.

In Composer-Setup for Windows before version 6.0.0, if the developer's computer is shared with other users, a local attacker may be able to exploit the following scenarios. 1. A local regular user may modify the existing C:\ProgramData\ComposerSetup\bin\composer.bat in order to get elevated command execution when composer is run by an administrator. 2. A local regular user may create a specially crafted dll in the C:\ProgramData\ComposerSetup\bin folder in order to get Local System privileges. See: https://itm4n.github.io/windows-server-netman-dll-hijacking. 3. If the directory of the php.exe selected by the user is not in the system path, it is added without checking that it is admin secured, as per Microsoft guidelines. See: https://msrc-blog.microsoft.com/2018/04/04/triaging-a-dll-planting-vulnerability.

Composer before 2016-02-10 allows cache poisoning from other projects built on the same host. This results in attacker-controlled code entering a server-side build process. The issue occurs because of the way that dist packages are cached. The cache key is derived from the package name, the dist type, and certain other data from the package repository (which may simply be a commit hash, and thus can be found by an attacker). Versions through 1.0.0-alpha11 are affected, and 1.0.0 is unaffected.