CVE-2026-48158

The standard supply chain playbook — yank the package, publish a CVE, tell users to update — is structurally inapplicable here because the malicious commits were never published to npm. A force-push removed them from the origin repository, but that operation does not reach local clones, forks that predated the push, direct-SHA references, or CI caches populated during the 24-hour window. There is no npm-level remediation to perform. The exploitable state persists indefinitely on every affected workstation, and there's no automated mechanism to close that gap. The attacker's code explicitly skipped CI execution and targeted only developer workstations — the high-value environment where credentials, VPN sessions, and cloud access live. This wasn't an oversight; it reflects understanding that CI is monitored and isolated while developer machines are not. The second-stage payload was attacker-hosted and designed to be unrecoverable, which means full forensic resolution is structurally impossible. Assume compromise occurred. For defenders: check git reflog on any clone that existed during the affected window — reflog entries persist through force-pushes and can reveal commits that no longer exist in any branch. Audit for the four affected SHAs. But recognize that many affected developers won't know to look, and there's no npm-level signal that propagates "check your history." This is the remediation horizon problem — the attack surface shrinks at the origin but persists in every local environment. The deeper issue is that `postinstall` scripts are an authorized execution channel built into npm's design. Every package can legitimately use them, and attackers can exploit that capability without touching npm at all. The ecosystem has no practical alternative, no sandboxing by default, and no instrumentation to detect violations at scale. The disclosed pattern — CI-skipping postinstall, force-push resistant, unrecoverable second stage — is now permanently available to any subsequent actor. The fix coordination problem is genuinely hard: Node.js, npm, and git are maintained by projects that aren't primarily security projects, with different governance and release cadences. The structural risk remains because developer experience has consistently been prioritized over security in this ecosystem, and the next CVE will exploit the same gap.

Reviewed through automated stages and approved by a human before publication.