npm supply-chain attack used trusted publishing to slip GHAPPIER into a legitimate package

Once in, the attacker reportedly made a small but consequential change: three lines were modified so that any push to the main branch would trigger the release workflow. Fourteen minutes later, CloudSEK said, the workflow was rewritten again so publishing could happen unattended. The build then ran through GitHub Actions using OIDC trusted publishing, with a Sigstore attestation in the public log naming the attacker’s commit, per Infosecurity Magazine.

That matters because the release appeared legitimate at the supply-chain level. As CloudSEK put it in comments quoted by the publication, the trust model verified the CI system identity and the build origin, not whether the source code being built had been honestly authored.

What GHAPPIER did

CloudSEK said the loader itself was just one line buried inside a 99KB file. From there, it kicked off a four-stage chain that ended in a general-purpose remote shell that deleted itself from disk while running, Infosecurity Magazine reported.

The malicious code reportedly did not execute during installation. Instead, it fired when the MCP server was launched. That means systems that installed version 0.2.21 but never started it would not have triggered the loader.

Scope and limits of the reported campaign

CloudSEK traced GHAPPIER across at least 65 public repositories, 73 infected files and 22 accounts, according to the report summarized by Infosecurity Magazine. Even so, the firm said it found no evidence of a successful compromise of any organization.

The episode highlights a narrower but important supply-chain risk: trusted publishing, attestations and signature checks can validate that a package came from the expected automated pipeline, yet still fail to stop malicious code if an attacker has already obtained legitimate repository access.