The Malicious npm Release Had Valid Provenance Because the Build System Worked
The poisoned package was not smuggled around the build system. GitHub Actions built it, npm trusted the workflow identity and Sigstore recorded the provenance. Every control accurately described a release created from an attacker’s commit.
CloudSEK calls the loader operation GHAPPIER. Its investigation began with version 0.2.21 of the legitimate @dforge-core/dforge-mcp package and expanded to at least 65 public repositories, 73 infected files and 22 accounts.
Push access became publish access
The intruder controlled the maintainer’s repository for 105 minutes on 9 September. They inserted a one-line remote loader, changed the workflow so pushes to the main branch triggered releases and published the malicious version without needing a separate npm token.
Trusted publishing did what it was configured to do. It accepted the repository’s CI identity. The resulting attestation points to the attacker’s real commit, which is valuable forensic evidence but not a verdict that the code was safe.
The package remained the latest release for 35 minutes and 38 seconds before the maintainer reverted the changes and published 0.2.22. CloudSEK says the later stages remained reachable five days after withdrawal.
The final implant removed itself
The first malicious line started a four-stage chain. The final implant deleted itself from disk at startup, so an organisation that removed the package and searched only for the last payload could reasonably reach the wrong conclusion.
CloudSEK also found a related payload pattern associated with the PolinRider campaign. Some attribution claims in the wider reporting point towards North Korea, but CloudSEK says its own independent check did not confirm that final attribution step. The documented supply-chain activity stands without it.
What maintainers and consumers should change
- Require protected branches, independent review and restricted workflow-file changes for release repositories.
- Treat GitHub push authority as production publishing authority when OIDC trusted publishing is enabled.
- Pin or upgrade the affected package to clean version 0.2.22 and investigate any execution of 0.2.21.
- Use the provenance record to identify the exact malicious commit and affected build, not as a substitute for source review.
- Hunt for intermediate artefacts and network behaviour because the final implant deletes itself.
- Revoke developer credentials and review other repositories reachable from the same workstation or account.
CloudSEK says it found no evidence that an organisation was successfully compromised through this release. The incident still exposes a dangerous misunderstanding: provenance can prove that a trusted factory produced the package while simultaneously proving that the factory received poisoned instructions.
Sources
- CloudSEK GHAPPIER investigation, published 20 September 2026.
