use-context-selector CVE-2026-48158

Exploitation requires obtaining and installing a git checkout that still contains the malicious commits 9d8481a…748641b through 6f2dae0…674124 - specifically a local clone, fork, mirror, or direct-commit-SHA URL captured while the default branch was poisoned (2026-05-18 15:57:18 to 2026-05-19 15:24:34 UTC) - and then running npm install (or any install that triggers the postinstall hook) against it. Additional required condition: outbound HTTPS reachability from the Node process to the attacker-controlled payload endpoint. Key LIMITING factors: the malicious code deliberately does NOT execute on CI or cloud/serverless environments (it targets interactive developer workstations only), the code was never published to npm so registry installs are safe, and the commits were force-removed from upstream so a fresh default-branch clone is not affected - meaning a non-default source (retained/forked history or pinned SHA) is a hard prerequisite.

This is a genuine high-priority event, not a paper-high-CVSS issue, but its real-world blast radius is bounded by an unusual delivery path. The published CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VC/VI/VA:H, score 9.3) reflects full confidentiality/integrity/availability loss on the victim host, which is accurate given arbitrary code execution as the developer. However AC:L/UI:N overstates ease: the malicious commits were force-pushed out of the default branch within ~24 hours and the package was never on npm, so a normal npm install use-context-selector from the registry or a fresh default-branch clone is NOT affected - exploitation now requires possessing a checkout, fork, or direct-SHA URL that still contains the malicious SHAs and then running an install against it, which in practice means user action and a non-default source. There is no CISA KEV listing and no reconstructable public exploit (the second stage was attacker-hosted and is gone), so this is not evidence of broad active exploitation; risk is concentrated among the specific set of developers who cloned/forked during the ~24-hour window. Anyone who did run npm install against an affected checkout on or after 2026-05-18 15:57:18 UTC should treat the workstation as fully compromised - even a small mid-sized operator or dev team fitting that profile should treat cleanup and credential rotation as urgent - because a single infected developer machine can pivot to source repos, cloud keys, and CI secrets.

A developer clones a fork or opens a direct-SHA URL of use-context-selector captured during the compromise window, or a CI/dev script pins an affected commit, and runs npm install. The postinstall hook silently fetches and evaluates the attacker's second-stage payload with the developer's privileges, which then harvests SSH keys, cloud tokens, and npm credentials and can pivot into source repositories and cloud accounts - with no public POC to reproduce since the second stage is no longer hosted.