Composer Command Injection (CVE-2026-40261, CVE-2026-40176): Any Malicious Repository Can Execute Code on Your Build Machines

Two high-severity vulnerabilities disclosed today in Composer — the de facto PHP dependency manager — allow arbitrary command execution through crafted repository metadata. The critical detail: one of the flaws carries a network attack vector, meaning any malicious package repository can trigger code execution on developer machines and CI/CD runners without requiring local file access.

What Happened

Composer’s Perforce VCS driver contains two distinct command injection points. Researchers disclosed both today alongside patches in Composer 2.9.6 (mainline) and 2.2.27 (LTS).

CVE-2026-40261 — syncCodeBase() injection (CVSS 8.8, Network AV)

The Perforce::syncCodeBase() method fails to properly escape source references before passing them to shell commands. An attacker controlling a package repository can include shell metacharacters in package metadata’s Perforce source declarations. When Composer resolves and syncs that package, the crafted source reference gets passed directly to a shell command.

Critically, Perforce does not need to be installed on the victim machine for this to be exploitable. The vulnerability fires during the metadata parsing and resolution phase, before any Perforce binaries are invoked. This means any composer install, composer update, or composer require targeting a malicious repository — private Packagist instance, compromised mirror, or attacker-controlled repository — can execute arbitrary commands with the privileges of the Composer process.

CVE-2026-40176 — generateP4Command() injection (CVSS 7.8, Local AV)

The Perforce::generateP4Command() method improperly escapes connection parameters: port, user, and client. An attacker who can influence a project’s composer.json — whether through a compromised dependency, a malicious pull request, or direct access — can inject commands through these Perforce connection parameters. This is a local attack vector but remains a realistic threat in shared development environments and in CI/CD pipelines that build from pull requests without sanitizing dependency declarations.

Affected Versions

Composer 1.x is end-of-life and not covered by this advisory, but also likely vulnerable.

Attack Scenarios

Scenario 1: Compromised private Packagist mirror. Your CI/CD pipeline runs composer install against a private mirror. An attacker who compromises that mirror (or its backing object storage) inserts a malicious package with a crafted Perforce source reference. Every build that installs or updates dependencies executes attacker-controlled commands. This is the fully remote, no-user-interaction path.

Scenario 2: Dependency confusion / typosquatting. A malicious package on packagist.org containing Perforce metadata with embedded shell commands. Any project that pulls the package gets code execution on install.

Scenario 3: Malicious pull request in open-source CI. An attacker submits a PR modifying composer.json to include a Perforce repository with injected connection parameters. The CI runner that builds the PR branch executes attacker commands — a common path for secrets exfiltration from CI environments.

Impact Assessment

PHP remains heavily deployed in enterprise applications, CMS platforms (WordPress, Drupal, Magento), and internal tooling. Composer processes run with developer-level or service-account privileges in most environments. A successful injection gives attackers:

• Command execution on build machines with full network access
• Access to environment variables (commonly containing API keys, cloud credentials, and secrets)
• Ability to persist via cron, SSH key injection, or modifying build artifacts
• Lateral movement from CI/CD runners into production environments

The network attack vector on CVE-2026-40261 is the more alarming of the two. Most teams don’t consider their package manager itself to be an attack surface when auditing their supply chain posture.

Mitigation

Immediate:

1. Update Composer now. Run composer self-update to get 2.9.6 (or composer self-update --2.2 for the LTS branch to get 2.2.27). Verify with composer --version.

2. Audit CI/CD environments. Ensure all build runners, Docker images used for PHP builds, and developer machines are updated. Pay particular attention to pinned Composer versions in Dockerfile or CI configuration files — these often lag behind.

3. Audit your Composer repository configuration. Review composer.json and auth.json for any Perforce VCS repository declarations. Most PHP projects don’t use Perforce; if yours does, treat those connections as high-risk until you’ve patched.

4. Restrict outbound repository access. If your builds shouldn’t be talking to arbitrary package sources, enforce this via network policy or Composer’s secure-http and allow-plugins configuration options.

Longer-term:

Consider locking Composer to a specific version in CI and implementing a verification step (checksum of the Composer phar) to detect unauthorized downgrades or substitutions. Running composer install with --no-scripts in untrusted contexts prevents arbitrary script execution but does not mitigate these specific injection vectors, which occur before script execution.

Vendor Response

The Composer project disclosed both CVEs alongside the patched releases. No exploitation has been reported prior to public disclosure, though proof-of-concept development is expected rapidly given the straightforward nature of the injection points.

Advisory: Composer Security Advisories — GHSA
Patch: Composer 2.9.6 release / Composer 2.2.27 LTS