"Provenance attests where an artefact was built, not whether its source was honest," CloudSEK said.
That distinction sits at the heart of a supply-chain compromise CloudSEK disclosed on September 20: attackers used a legitimate maintainer account to publish a malicious release of the npm package @dforge-core/dforge-mcp, shipping a previously unreported loader dubbed GHAPPIER while carrying a valid provenance attestation in Sigstore's public log.
How attackers abused npm trusted publishing and OIDC
CloudSEK's report says an attacker controlled the maintainer account for 105 minutes on September 9. During that window an initial malicious release, version 0.2.20, failed and broke installation of the package; a follow-up release, 0.2.21, successfully shipped the loader and remained the latest published version for 35 minutes and 38 seconds.
The attacker already had push access to the repository's main branch. CloudSEK could not establish precisely how that push access was obtained but raised the possibility of a developer machine infected by a malicious extension or package. The attacker edited three lines so that any push to main would start the repository's release workflow, and then—14 minutes later—rewrote the workflow so it could publish unattended.
The build executed in GitHub Actions using OIDC trusted publishing; its attestation is present in Sigstore's public log and names the attacker's commit. Because the registry trusts the repository's CI identity, CloudSEK noted, "push access was publish access, and the release would pass npm audit signatures." In short: a CI-origin attestation showed where the artifact was built, but did not prove the repository's source code had been honest.
The GHAPPIER loader: one line, a four-stage chain and a transient shell
GHAPPIER's initial payload was deceptively small. CloudSEK found the loader as one line inside a 99KB file that opened a four-stage chain ending in a general-purpose remote shell. That final-stage implant deleted itself from disk as it ran.
Notably, the loader activated when the MCP server was launched rather than on package installation. Systems that installed version 0.2.21 but never started the server therefore did not execute the loader. CloudSEK reported no evidence that GitHub, npm, or any package repositories were directly exploited: "Every action in this report is an authorised action taken with a stolen key," the firm wrote.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildTracing GHAPPIER and a link to PolinRider’s technique
CloudSEK mapped GHAPPIER across at least 65 public repositories, 73 infected files and 22 accounts. Within that activity the investigators found a second payload that exactly matched PolinRider, a campaign OpenSourceMalware has tracked since March 2026.
That PolinRider-like payload reads configuration from an empty Ethereum transaction that costs about $0.20 to publish. CloudSEK highlighted the operational effect: the use of an on-chain, minimal-cost transaction leaves "no domain to suspend or host to seize." Other researchers attribute PolinRider to North Korea, but CloudSEK said its single independent check did not confirm that attribution.
CloudSEK judged PolinRider's documented credential-harvesting capability the likeliest route into the maintainer account used to publish 0.2.21, and the company said it found no evidence of a successful compromise of any organization.
Practical mitigations CloudSEK recommends
CloudSEK offered specific, actionable steps for defenders in the wake of the incident. They include pinning the package to version 0.2.22 and treating any lockfile that pins 0.2.21 as an immediate indicator of possible exposure. Rather than chasing the implant itself, CloudSEK advised sweeping for the artifacts the chain leaves behind.
The report also recommended alerting on changes to a release workflow's trigger block—a change that, in this case, occurred 14 minutes before the workflow could publish—because those edits can convert simple repository push rights into full publish capability under CI-trusted identities.
What this means for open-source maintainers, security teams, and enterprises
- Open-source maintainers: Review CI workflows for unexpected changes to trigger blocks and harden account credentials; credential harvesting is the pathway CloudSEK identifies as most likely in this campaign.
- Security and DevOps teams: Treat lockfiles pinning 0.2.21 as an indicator, sweep for the multi-stage artifacts CloudSEK describes rather than relying solely on signature or provenance checks, and consider alerts when workflows are edited to add new triggers.
- Enterprises and procurement leaders: Recognize that a valid provenance attestation indicates where an artifact was built by CI but not whether the repository or maintainer was honest; pinning to 0.2.22 is the specific recommendation CloudSEK provided in this case.
CloudSEK published its findings on September 20; as of that report no advisory had appeared in OSV, the GitHub database or from the maintainer, and every stage of the chain still responded five days after the withdrawal. The incident underscores a narrow but significant point: attestation can verify origin, but it cannot prove intent or the integrity of a maintainer's keys—particularly when those keys or accounts may have been compromised.
https://www.infosecurity-magazine.com/news/attackers-abuse-npm-trusted/
