Composer is a dependency Manager for the PHP language

Composer trusts package names too much. A crafted name in a composer.json requirement (or in a package resolved transitively from an untrusted repository) can escape the vendor/ directory during install/update, writing arbitrary files anywhere the Composer process has permission. In practice that means dropping a .bashrc, ~/.ssh/authorized_keys, or a cron entry — turning a dependency pull into arbitrary code execution as the user running composer. Affected: Composer 1.0 through 2.2.28 and 2.3.0 through 2.10.1. Fixed in 2.2.29 and 2.10.2 (GHSA-499r-g7pc-vmp9).

The vendor's HIGH / 7.0 rating is defensible and we're keeping it. The CVSS vector (AV:L/AC:H/PR:N/UI:R) accurately reflects that this is not a wormable network flaw — it needs a malicious package and a user action to install it. But CVSS underweights *where Composer actually runs*: CI runners, container build stages, and dev workstations with SSH keys and cloud credentials. Arbitrary file write on any of those is not a workstation nuisance — it's a foothold in the supply chain.

Why this verdict

• Vendor baseline is fair. 7.0 accurately captures a local, UI-required file-write-to-RCE bug. Nothing about the underlying tech screams underrated.
• Friction adjustment: −0.5. Needs a malicious package on a repository the victim consumes, needs a composer install/update, and needs write access to a meaningful target. Enterprise Packagist mirrors and committed composer.lock files kill most opportunistic attempts.
• Role multiplier: +1.0 — floor is HIGH. Composer's canonical deployment includes CI/CD build servers (Jenkins, GitLab Runner, GitHub Actions self-hosted, Bitbucket Pipelines, Bamboo). File write on any of those = access to build secrets, artifact-signing keys, and downstream distribution. That is a supply-chain pivot, and it easily represents ≥10% of the installed base — Composer is *native* to build servers, not a peripheral. The HIGH floor is firm.
• Role multiplier: +0.0 on dev workstations. Compromised laptop = one developer's git creds, cloud tokens, SSH keys. Bad, but bounded. Doesn't push the score higher on its own.
• No exploitation multiplier. EPSS 0.13%, no KEV, no PoC. This is not a 'drop everything' bug — it is a 'patch it in the normal HIGH lane' bug.

Why not higher?

No active exploitation, no public PoC, and the delivery mechanism requires an attacker to first get a malicious package into your dependency graph — a non-trivial prerequisite for any organization that uses Private Packagist, a proxy repo (Nexus/Artifactory), or committed lockfiles. CRITICAL is reserved for chains that are network-reachable or have KEV evidence; this is neither.

Why not lower?

MEDIUM would ignore the deployment-role reality: Composer runs on CI, and file-write-to-RCE on CI is a supply-chain vector. The role multiplier explicitly floors this at HIGH — friction alone cannot pull it below. Even if you have strong dev-workstation controls, a single unpinned dependency on one build agent is enough for full impact.

1. Upgrade Composer to 2.10.2 (or 2.2.29 on the LTS branch) fleet-wide — This is the actual fix. Push it via your config-management tool (Ansible/Chef/Puppet), your base container images, and your CI runner provisioning. Deploy within 30 days per the noisgate mitigation SLA for HIGH — but on CI/build hosts, treat as the top of the queue and aim for 7 days.
2. Route all Composer traffic through a private proxy (Private Packagist, Nexus, Artifactory, Toran Proxy) — Prevents unreviewed third-party repositories from reaching your build hosts. Even after patching, this is the single highest-leverage supply-chain control for PHP shops. Deploy within 30 days.
3. Commit and enforce composer.lock in every PHP repository, and require composer install (not update) in CI — Locks the exact package name+version set. A malicious name can't be resolved unless it's already in the lockfile — which turns the attack into an obvious PR-review event. Roll out via repo-template policy and CI linter.
4. Enable file-integrity monitoring on CI runners and dev workstations for ~/.ssh/, ~/.bashrc, ~/.zshrc, ~/.profile, /etc/cron.*, /etc/profile.d/ — Detects the exploit primitive directly, regardless of which CVE delivered it. Feed alerts to SIEM with high priority when the writing process is php or composer.
5. Move CI to ephemeral runners with read-only base images — Even if exploitation succeeds, the container is destroyed at job end and the payload can't persist. Combine with just-in-time secret injection (OIDC-federated cloud creds, short-TTL vault leases) to minimize what any single compromised job can steal.

Run on each host that has Composer installed — dev workstations, CI runners, build agents, container base images. Invoke as bash check-composer-59948.sh with no arguments; needs only read access to the composer binary in PATH. Exits 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN.

#!/usr/bin/env bash
# check-composer-59948.sh
# Detects Composer versions vulnerable to CVE-2026-59948 (arbitrary file write via package name)
# Fixed in 2.2.29 (LTS) and 2.10.2
set -u

COMPOSER_BIN="$(command -v composer || true)"
if [ -z "$COMPOSER_BIN" ]; then
  # Also try common alt locations
  for c in /usr/local/bin/composer /usr/bin/composer ~/.composer/vendor/bin/composer /opt/composer/composer.phar; do
    [ -x "$c" ] && COMPOSER_BIN="$c" && break
  done
fi

if [ -z "$COMPOSER_BIN" ]; then
  echo "UNKNOWN: composer binary not found in PATH or common locations"
  exit 2
fi

VER_LINE="$($COMPOSER_BIN --version --no-ansi 2>/dev/null | head -n1)"
# Example: "Composer version 2.7.1 2024-02-09 15:26:28"
VER="$(echo "$VER_LINE" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)"

if [ -z "$VER" ]; then
  echo "UNKNOWN: could not parse version from: $VER_LINE"
  exit 2
fi

# Split version
IFS='.' read -r MAJ MIN PATCH <<< "$VER"

vuln=1  # assume vulnerable until proven otherwise

if [ "$MAJ" -eq 2 ] && [ "$MIN" -ge 3 ]; then
  # 2.3.0 - 2.10.1 vulnerable; 2.10.2+ patched
  if [ "$MIN" -gt 10 ] || { [ "$MIN" -eq 10 ] && [ "$PATCH" -ge 2 ]; }; then
    vuln=0
  fi
elif [ "$MAJ" -eq 2 ] && [ "$MIN" -le 2 ]; then
  # 2.0.0 - 2.2.28 vulnerable; 2.2.29+ patched on LTS branch
  if [ "$MIN" -eq 2 ] && [ "$PATCH" -ge 29 ]; then
    vuln=0
  fi
elif [ "$MAJ" -ge 3 ]; then
  # Future majors assumed patched
  vuln=0
fi

if [ "$vuln" -eq 0 ]; then
  echo "PATCHED: composer $VER at $COMPOSER_BIN"
  exit 0
else
  echo "VULNERABLE: composer $VER at $COMPOSER_BIN — upgrade to 2.10.2 (or 2.2.29 on LTS)"
  exit 1
fi

Sources

1. GHSA-499r-g7pc-vmp9 — Composer advisory
2. Composer 2.10.2 release notes
3. Composer releases index
4. The Hacker News — Composer flaws coverage
5. Laravel News — Composer security fixes
6. OpenCVE — getcomposer vendor page
7. MITRE CVE search — composer php
8. CTIWatch — sibling CVE-2026-59946