Provenance Fails as npm Supply Chain Attack Hits

When a malicious npm package carries valid provenance, the security assumption that signed builds equal safe code breaks down. CloudSEK's September 2026 report on the GHAPPIER campaign shows how attackers turned npm's trusted publishing feature against the ecosystem, sliding a previously unreported loader into a legitimate package while leaving a cryptographically signed paper trail that would pass automated checks.

The incident raises uncomfortable questions about what provenance actually proves, and whether the trust placed in CI identities needs rethinking. For defenders, the episode is a reminder that supply chain security is only as strong as the weakest link in the maintainer's environment.

How the GHAPPIER loader was delivered

According to CloudSEK's report, the attacker used the maintainer account of @dforge-core/dforge-mcp for 105 minutes on September 9. During that window, they pushed two malicious releases. The first, version 0.2.20, failed and broke installation of the package. The second, 0.2.21, successfully shipped the loader and remained the latest version for 35 minutes and 38 seconds.

The attacker already had push access to the main branch, though CloudSEK said it could not establish how that access was obtained. The firm suspects a developer machine infected by a malicious extension or package provided the initial foothold.

Provenance attests build, not intent

To pull off the release, the attacker modified three lines so that any push to the main branch would trigger the release workflow. Fourteen minutes later, they rewrote the workflow to allow unattended publishing. The build executed through GitHub Actions using OIDC trusted publishing, and its attestation remains in Sigstore's public log, naming the attacker's commit.

"Provenance attests where an artefact was built, not whether its source was honest," CloudSEK said.

— CloudSEK, in its report

Because the registry trusts the repository's CI identity, push access effectively became publish access. The malicious release would pass npm audit signatures, meaning standard integrity checks would not flag it. The attestation verified the build environment, but not the intentions of the person who triggered it.

Inside the four-stage delivery chain

The loader itself was a single line hidden inside a 99KB file. It opened a four-stage chain that ended in a general-purpose remote shell, which deleted itself from disk as it ran. Crucially, the loader fired when the MCP server was launched, not during installation. Systems that installed version 0.2.21 but never started it did not execute the malicious code.

CloudSEK found no exploitation of GitHub, npm, or any package. In its report, the firm stated: "Every action in this report is an authorised action taken with a stolen key." That distinction matters: the attacker didn't break the platform's security controls; they used legitimate credentials to abuse trusted features.

Scale of the campaign and links to PolinRider

CloudSEK traced GHAPPIER across at least 65 public repositories, 73 infected files, and 22 accounts. A second payload, found in another victim's repository, exactly matched PolinRider, a campaign that OpenSourceMalware has tracked since March 2026.

That second payload read its configuration from an empty Ethereum transaction costing about $0.20, a technique that leaves no domain to suspend or host to seize. While other researchers attribute PolinRider to North Korea, CloudSEK said its one independent check did not confirm that attribution.

Likely entry point and lack of advisories

CloudSEK said PolinRider's documented credential harvesting is the likeliest route into the maintainer account. The firm found no evidence of a successful compromise of any organization.

As of the report, no advisory had appeared in OSV, the GitHub database, or from the maintainer, though every stage of the chain still responded five days after the withdrawal. That silence leaves defenders without official guidance from the usual sources.

Recommended mitigations

CloudSEK advised pinning the package at version 0.2.22 and treating any lockfile that pins 0.2.21 as an indicator of compromise in itself. The firm also recommended sweeping for the artifacts the chain leaves behind rather than hunting for the implant, and alerting on changes to a release workflow's trigger block, which in this case came 14 minutes before the workflow could publish.

These steps reflect the specific mechanics of the attack: the malicious release is gone, but the traces it left in CI configurations and lockfiles can still reveal exposure.

Why this matters for software supply chains

The GHAPPIER campaign demonstrates that provenance attestations are not a silver bullet. They verify the build process, but they cannot vouch for the integrity of the source code or the intentions of the person who controls the repository. When an attacker gains push access through a compromised maintainer account, the resulting release will carry all the markings of a legitimate build.

For organizations that rely on npm packages, this suggests a need to look beyond automated signature checks. Monitoring for changes to release workflows, pinning dependencies, and treating lockfiles as potential indicators could help catch similar attacks earlier. The incident also highlights the value of runtime detection: because the loader executed only when the MCP server was launched, systems that installed but didn't run the package escaped infection. That nuance may inform how teams assess exposure after a supply chain alert.

As supply chain attacks grow more sophisticated, the security community may need to reevaluate what trust signals actually mean. Provenance is a useful tool, but it is not a guarantee of safety. The GHAPPIER case shows that even a signed, attested release can be malicious if the underlying account is compromised.