Attackers abused npm trusted publishing to distribute a previously unreported loader called GHAPPIER through a legitimate package, showing how software provenance can confirm where a release was built without proving the underlying source was safe. In reporting on CloudSEK’s findings, Infosecurity Magazine said the malicious npm release carried valid provenance even though it had been altered by an attacker.
CloudSEK said someone used the maintainer account for @dforge-core/dforge-mcp for 105 minutes on September 9. A first malicious release, version 0.2.20, failed and broke installation. A follow-up release, 0.2.21, successfully shipped GHAPPIER and remained the latest version for 35 minutes and 38 seconds, Infosecurity Magazine reported.
How the release pipeline was turned against itself
According to CloudSEK, the attacker already had the ability to push to the repository’s main branch, though the firm said it could not determine exactly how that access was obtained. Its suspicion, as relayed by Infosecurity Magazine, is that a developer machine may have been compromised by a malicious browser extension or 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 but never started it would not have triggered the loader.
