Composer CVE-2026-59948

Exploitation requires the victim to have configured a repository OTHER than Packagist.org or Private Packagist (an untrusted custom 'repositories' entry) and to install or update a maliciously crafted package whose invalid, unvalidated package name carries the traversal payload; the attack only fires when the developer or CI actually runs 'composer install' or 'composer update' (UI:R). Limiting factors: it does NOT work against the default trusted Packagist/Private Packagist configuration, the CVSS attack complexity is High and the vector is Local (AV:L), and it depends on the victim both trusting a hostile repository and executing a Composer operation - so realistic risk is confined to supply-chain, self-hosted-mirror, or targeted-setup situations rather than default-configuration remote exploitation.

The CVSS 3.1 vector CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H (7.0, High) reflects a locally-triggered, high-complexity attack that needs user interaction (running install/update) but no pre-existing privileges, with high confidentiality, integrity and availability impact once an attacker-controlled file is written outside the project. The realistic priority is moderate rather than urgent: the AC:H and UI:R metrics, combined with the description's precondition that the victim must already trust and configure a hostile non-Packagist repository, confine exploitation to supply-chain or targeted-setup scenarios rather than opportunistic mass exploitation. No EPSS score, KEV listing, POC, or SSVC decision data was provided in the input, so exploitation likelihood cannot be quantified - the absence of KEV/POC signals suggests no observed active exploitation, but that is inferred from missing data, not confirmed. The C:H/I:H/A:H rating is vendor/NVD-assigned; an arbitrary file write outside the project can plausibly escalate to code execution depending on where the file lands, which justifies the high impact metrics.

An attacker publishes a package with a deliberately invalid, traversal-laden name on a third-party Composer repository and persuades a developer to add that repository and require the package (for example via a tutorial, fork, or compromised internal mirror). When the developer runs 'composer install' or 'composer update', Composer writes the attacker-controlled file outside vendor/ and outside the project - for instance dropping a script into a startup or webroot path - potentially leading to code execution. No public exploit code has been identified at time of analysis.