CVE-2026-84361 in Composer
Summary
by MITRE • 09/02/2026
Composer is a dependency Manager for the PHP language. From 1.0 until 2.2.30 and 2.10.3, a malicious dependency package from a custom Composer repository or an untrusted composer.lock file could set source.type to perforce and source.url to an rsh: or jsh: P4PORT value. When the Perforce p4 client was installed and Composer installed the package from source through composer install or composer update, including --prefer-source, Composer\Util\Perforce passed the address to p4 without validation, causing p4 to run a local command with the privileges of the user or CI account. Packagist.org does not permit Perforce source metadata. This issue is fixed in versions 2.2.30 and 2.10.3.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified involves Composer, a widely used dependency manager for the PHP programming language, specifically affecting versions from 1.0 through 2.2.30 and 2.10.3. This security flaw stems from an improper validation of source control metadata within the Perforce integration module. When developers or automated systems utilize composer install or composer update commands, particularly with flags such as --prefer-source to fetch packages directly from their version control repositories rather than using archived releases, Composer processes the source configuration defined in package metadata or lock files. The specific technical failure occurs when a malicious dependency package is sourced from a custom repository or an untrusted composer.lock file that has been tampered with by an attacker.
The core of the vulnerability lies in how Composer handles the source.type and source.url fields for Perforce repositories. An attacker can craft a package definition where the source type is set to perforce, but more critically, they can manipulate the source URL field to contain values prefixed with rsh: or jsh:. These prefixes are specific connection protocols used by the Perforce p4 client command-line tool to establish remote sessions using different authentication and transport mechanisms. In a normal operational context, these fields should point to standard TCP/IP host-port pairs for connecting to a Perforce server. However, because Composer passes this URL string directly to the underlying system shell without performing adequate sanitization or validation of the protocol prefix, it allows an attacker to inject arbitrary command-line arguments into the p4 execution flow.
When the target environment has the Perforce client software installed and configured, executing composer install triggers the invocation of the p4 binary with these maliciously crafted parameters. The lack of input validation means that the rsh: or jsh: prefixes are interpreted by the p4 client as instructions to use remote shell connections rather than standard network sockets. This behavior can lead to a Remote Code Execution scenario, depending on how the local system is configured and what privileges the user running Composer holds. If the command runs under an account with elevated permissions, such as a continuous integration service account or a developer's administrative profile, the attacker gains the ability to execute arbitrary commands on that host with those same privileges. This effectively bypasses standard network-based access controls by leveraging local system execution capabilities initiated through a dependency management tool.
The operational impact of this vulnerability is significant for organizations relying on automated build pipelines and shared development environments. Since Packagist.org, the default public repository for PHP packages, explicitly prohibits Perforce source metadata in its package definitions, this attack vector primarily targets projects that utilize custom internal repositories or have been compromised via a poisoned composer.lock file distributed through other channels such as email attachments or untrusted code sharing platforms. The risk is exacerbated by the fact that many CI/CD systems run build processes with high-level privileges to facilitate deployment tasks, making them attractive targets for privilege escalation attacks originating from seemingly benign dependency updates.
To mitigate this vulnerability, organizations must immediately upgrade their Composer installations to version 2.2.30 or 2.10.3 and later, where the issue has been resolved through improved input validation mechanisms that prevent the injection of dangerous protocol prefixes into system commands. In environments where upgrading is not immediately feasible, it is critical to enforce strict verification of composer.lock files before they are committed to version control or used in builds. Developers should avoid using --prefer-source flags unless absolutely necessary and ensure that custom repositories only serve packages from trusted sources with verified integrity. Additionally, restricting the permissions of CI/CD service accounts can limit the blast radius if such an execution attempt were to succeed.
From a classification perspective, this vulnerability aligns with CWE-94, which describes Improper Control of Generation of Code (Code Injection), as it involves the construction of executable commands from untrusted input without proper neutralization of special elements. It also relates to CWE-20, Improper Input Validation, specifically regarding the failure to validate protocol schemes in URL structures before passing them to system utilities. In terms of adversary tactics, this exploit maps to ATT&CK technique T1059, Command and Scripting Interpreter, where attackers use local scripts or commands to execute malicious actions on a compromised host. The attack path typically involves Initial Access through social engineering or supply chain compromise followed by Execution via the vulnerable dependency manager tool.