The Perforce Driver You Never Knew You Had: Composer CVE-2026-40261 and CVE-2026-40176

Sat, 23 May 2026 10:00:00 -0500

Update Composer to 2.9.6 or 2.2.27 LTS now. If that sentence is enough, you’re done. If you want to understand why this one is worth a closer look, keep reading.

Background: the Composer maintainers published their own writeup of these advisories on the Packagist blog. The technical details and the registry-level mitigations described below come from that post; this piece is the operator’s read for commerce teams.

Quick Refresher: Composer, Drivers, and Why Perforce Is in There

If you don’t live in PHP-land daily, this advisory reads as opaque, so a thirty-second primer.

Composer is the dependency manager every modern PHP project uses. For Magento and Adobe Commerce specifically, it is how the core platform itself ships and how every module — first-party, third-party, your own internal libraries — gets installed and updated. When a developer runs composer install on a fresh Magento checkout, Composer reads composer.json, resolves the dependency graph, downloads each package, and assembles vendor/. When CI deploys a release, it runs the same command. There is no Magento install today that does not run Composer many times a day.

A composer.json lists each dependency along with where to fetch it from. Most packages come from Packagist (the public PHP registry) or its commercial sibling Private Packagist. But you can also point Composer directly at a source-control repository — a git URL, a mercurial repo, a subversion checkout, or a Perforce depot. To do that, you declare a repository in composer.json with a type: field naming which version-control system to use. Composer ships with a VCS driver for each supported type — git, svn, hg, fossil, perforce — that knows how to clone, list versions, and fetch source from that system.

The Perforce driver is one of those bundled drivers. It exists because Perforce is the dominant version-control system in game studios, large enterprises with legacy commercial codebases, and some sectors of finance and manufacturing — places where PHP shops occasionally need to pull a package from a Perforce depot. The driver is shipped with Composer by default. It loads regardless of whether you have ever configured a Perforce repository. That last point is the whole story of this CVE.

The Perforce Driver Is Loaded Whether You Use It or Not

CVE-2026-40261 and CVE-2026-40176 are both in Composer’s Perforce VCS driver - the code that handles repositories declared as perforce type in a composer.json. Neither requires Perforce to be installed. Both allow arbitrary command execution in the context of whatever runs composer install or composer update.

That’s the part the advisory buries in the third paragraph. Most Magento shops have never configured a Perforce repository and have no intention of doing so. That doesn’t matter. The vulnerable code path loads regardless, and an attacker-controlled composer.json or package metadata can reach it.

Two Different Attack Surfaces

CVE-2026-40176 requires the attacker to control the composer.json you’re actually running - the root manifest. The injected values are Perforce connection parameters (port, user, client) that get interpolated into shell commands without escaping. This is the local-project risk: if you’re running Composer commands on a project from an untrusted source, this fires.

CVE-2026-40261 is the wider problem. It affects the syncCodeBase() method, which handles a source reference parameter that can come from package metadata - not just the root composer.json. That means any Composer repository, including a compromised or malicious third-party repository, can serve package metadata that exploits this. You don’t have to touch the root manifest. You just have to install or update a dependency from source.

The trigger condition: installing dev-prefixed versions (anything before 1.0.0, or packages with dev- prefix) defaults to –prefer-source in Composer. Commerce agencies running Magento module development pipelines almost certainly have some dev-constraint packages in their dependency tree.

What This Means for a Magento and Commerce Pipeline

Enterprise commerce platforms run layered dependency graphs. The core is typically Magento/Adobe Commerce, which comes from the Magento Composer repository. Third-party modules come from a mix of Packagist, private repositories, and occasionally vendor-managed repos. Development workflows - module builds, staging deploys, CI pipelines - regularly operate with dev- constraints to pull HEAD on in-development extensions.

In that environment, CVE-2026-40261 is not hypothetical. Any point in the supply chain where package metadata can be influenced - a compromised private repo, a package repository serving malicious metadata, a CI secret that got rotated too late - becomes a command injection entry point into your build environment. The build environment has access to credentials, cloud provider tokens, and staging infrastructure that production doesn’t expose directly.

The patch notes say there’s no evidence of exploitation prior to publication. That’s the standard disclosure language and it’s worth taking at face value. It also doesn’t change the update calculus.

Packagist and Private Packagist Already Moved

Packagist.org disabled Perforce source metadata on April 10, 2026 as a precaution. Private Packagist did the same. If your dependencies come exclusively from these sources and you’re not running –prefer-source against anything that reaches Perforce metadata, your exposure was already mitigated at the registry layer.

If you run Private Packagist Self-Hosted, the new release is dropping now - and you should scan your installation using the verification command the release announcement documents before relying on the registry-level mitigation.

The Practical Calls

Run composer.phar self-update on every machine and CI runner that executes Composer commands. This includes local dev environments - dev machines are a vector, not just pipelines.
If you can’t update immediately, –prefer-dist in your installs eliminates the CVE-2026-40261 exposure by avoiding the source-fetch path. It’s a workaround, not a fix.
For CVE-2026-40176: review any composer.json files you run Composer commands against and aren’t fully trust-anchored. If your dev workflow clones external projects and runs composer install on them without inspection, that’s a habit worth fixing regardless of this CVE.
Audit your private Composer repositories for Perforce-type source declarations. These should not exist in commerce dependency graphs. If they do, understand why.

This is a straightforward dependency update with a clear fix. The reason it’s worth editorial attention is the “doesn’t affect Perforce users” misread - the relevant audience here is every team running a PHP/Composer-based build pipeline, which in the commerce world is essentially everyone.

Three Signals from November: What the Bulletins Don't Say

Wed, 26 Nov 2025 09:00:00 -0500

Three items from the November 2025 bulletin queue, taken individually, look like routine security hygiene. Together they tell a different story.

The Setup: Xurum Is Still Running Playbooks from 2022

The Xurum webshell campaign that Akamai documented isn’t new technique — it targets a known Magento vulnerability and deploys a sophisticated webshell that fingerprints server environment, exfiltrates payment data, and provides persistent shell access. What’s notable is that the campaign is still running, which means:

A meaningful percentage of Magento installs are still unpatched against a well-documented attack chain.
The attacker tooling has matured — Xurum has environment-awareness that older skimmer campaigns lacked.

The practical read for commerce ops teams: if you’re running a Magento instance and haven’t validated your patching posture against Akamai’s published indicators, do that before reading the rest of this.

The Risk That Patch Notes Don’t Quantify: CVE-2025-54236

CVSS 9.1. Adobe Commerce. No user interaction required. Session takeover.

The APSB25-88 advisory covers an improper input validation vulnerability affecting Adobe Commerce through 2.4.8-p2 and back to 2.4.4-p15. What the advisory doesn’t foreground: in a multi-store environment where admin sessions are long-lived (common in managed service deployments), “session takeover” means an attacker who can reach your admin panel URL has a path to full platform control without needing to know a single credential.

The patch is available. The gap is the deployment window. A vulnerability that requires no user interaction closes fast in the wild once PoC code circulates — and for a CVSS 9.1 Adobe Commerce advisory, that window is short. If you’re on any affected version and your deployment pipeline adds days of testing overhead before applying security patches, that’s the thing worth fixing.

The Sleeper: CVE-2025-64174 and Admin DB Access Assumptions

The Magento-lts stored XSS (fixed in 20.16.0) requires an admin with direct database access or control over the admin notification feed source. That sounds narrow. It isn’t.

In practice, multi-vendor commerce deployments frequently involve third-party integrations that touch the database directly — ETL pipelines, ERP connectors, PIM syncs. Any of those that write to notification tables or translation strings without sanitizing output are an injection vector that bypasses the application layer entirely. The “requires admin DB access” framing in the CVE undersells the real-world exposure surface.

The Pattern

All three of these point at the same underlying gap: Commerce platform security posture is often evaluated at the application layer (patches applied, WAF rules updated) while the actual attack surface extends further — into long-lived sessions, admin-adjacent integrations, and deployment lag. The bulletins report what’s been patched. The editorial job here is flagging what that means for how you run the platform.

That’s what this blog is for.

Blog on Experience Digest