Critical Composer Flaws (CVE-2026-40176): RCE via Perforce Driver - Patch ASAP!
Has anyone else looked into the new Composer advisories dropped today? There are two high-severity command injection flaws (CVE-2026-40176 and a related CVE) specifically impacting the Perforce VCS driver. If you're using Perforce in your CI/CD pipelines with Composer, this is a critical RCE risk.
The vulnerability allows an attacker to execute arbitrary commands by manipulating the VCS configuration. Since Composer often runs with elevated privileges in containerized builds, the blast radius could be significant if an attacker can poison a dependency or the composer. file.
Patches are out, but I know many shops have legacy codebases. I threw together a quick Python snippet to scan for Perforce usage in composer. files across your repos, just in case your SBOM doesn't catch custom VCS drivers:
import os
import
def audit_vcs_repos(root_dir):
for subdir, dirs, files in os.walk(root_dir):
if 'composer.' in files:
filepath = os.path.join(subdir, 'composer.')
try:
with open(filepath, 'r') as f:
data = .load(f)
if 'repositories' in data:
for repo in data['repositories']:
if repo.get('type') == 'vcs' and 'perforce' in repo.get('url', '').lower():
print(f'[!] Found Perforce VCS in: {filepath}')
except Exception as e:
continue
audit_vcs_repos('.')
For those hunting in the logs, you'll want to look for PHP processes spawning unexpected child shells or interacting with p4 executables.
How is everyone handling dependency updates for obscure package managers? Is anyone else surprised to see Perforce still in use in 2026?
Thanks for the snippet. We actually still have a few legacy apps using Perforce because of how they handle large binary assets. I'm rolling out the update across our dev servers immediately. If you're managing this via Ansible, make sure you run the self-update command as the build user to avoid permission issues with the cached Phar file:
composer self-update --2
It's a pain to restart the build agents, but better than a supply chain compromise.
This is a nasty one because it bypasses the typical 'trusted source' checks. If an attacker can manipulate the repository URL in the composer. to point to a malicious Perforce depot, the injection happens before the package code even executes.
From a pentest perspective, check if you can simply append a pipe | or semicolon ; into the URL field of the repository definition in a test repo to verify if your version is vulnerable before patching.
Great discussion. For teams that can't patch immediately, I recommend auditing your dependency trees to ensure the perforce driver isn't implicitly loaded. A quick grep across your codebase helps identify exposure fast.
grep -r "\"type\": \"perforce\"" ./ --include="*."
As a temporary network control, consider restricting outbound traffic from your CI runners to known Perforce depot IPs. This limits the blast radius if a malicious composer. slips in before the update.
Solid advice on the audit, Derek. If patching isn't immediate, consider runtime detection via eBPF or Falco. You can set a rule to alert if composer spawns a shell or p4 with specific shell operators like && or |.
Here is a basic Falco rule to catch the behavior:
- rule: Detect Perforce Injection
desc: Detect command injection via composer
condition: >
spawned_process and proc.pname in (composer_bin) and
proc.name = sh and proc.args contains "p4"
output: "Suspicious shell spawned by composer (user=%user.name)"
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access