Attackers Abuse npm Trusted Publishing in GHAPPIER Supply Chain Campaign
A sophisticated supply chain attack leveraged npm's trusted publishing to inject the GHAPPIER loader into a legitimate package, highlighting risks even with strong provenance attestation.
Security researchers have uncovered a sophisticated supply chain attack where threat actors compromised a maintainer account for the npm package @dforge-core/dforge-mcp. The attackers successfully injected a previously unknown loader, dubbed GHAPPIER, into the package via GitHub Actions' trusted publishing mechanism. This incident underscores a critical vulnerability in software supply chains: while provenance attestation can confirm the build environment, it does not guarantee the integrity or honesty of the source code.
The malicious activity occurred on September 9, when an attacker gained control of the maintainer account for approximately 105 minutes. During this window, two releases were attempted. The first, version 0.2.20, failed and disrupted the package's installation process. However, the subsequent release, version 0.2.21, successfully shipped the GHAPPIER loader and remained the latest version for over 35 minutes. CloudSEK, the research firm that detailed the attack, noted that the attacker was able to push directly to the main branch, though the exact method of compromise for this access remains unclear, with infection via a malicious browser extension or package on a developer's machine being suspected.
A significant aspect of this attack is its exploitation of GitHub Actions' OIDC trusted publishing. The build process, executed through GitHub Actions, generated an attestation that was logged in Sigstore's public log, cryptographically linking the artifact to the attacker's commit. This highlights a crucial distinction: provenance confirms *where* an artifact was built, not *what* was built. Because the npm registry implicitly trusts the CI identity provided by the repository, the malicious release passed npm audit signatures, demonstrating how valid build credentials can be used to distribute malicious code.
The GHAPPIER loader itself was a single line within a 99KB file. It initiated a four-stage payload chain that ultimately established a general-purpose remote shell. Notably, this shell was designed to self-delete from the disk as it executed, making forensic analysis more challenging. The loader was triggered upon the launch of the MCP server rather than during installation, meaning systems that installed version 0.2.21 but did not run the associated server would not have been compromised by the loader.
CloudSEK's investigation found no evidence of exploitation of GitHub, npm, or any other package. Instead, the attack relied on the misuse of legitimate access credentials. "Every action in this report is an authorised action taken with a stolen key," the researchers stated, emphasizing that the compromise stemmed from stolen credentials rather than a direct vulnerability in the platforms themselves.
Further analysis revealed a connection between GHAPPIER and the PolinRider campaign, a threat operation that OpenSourceMalware has been tracking since March 2026. A second payload discovered in another victim's repository bore a striking resemblance to PolinRider's known tools. This payload's configuration was embedded within an empty Ethereum transaction, a technique that makes its command-and-control infrastructure highly resilient and difficult to disrupt. While some researchers attribute PolinRider to North Korea, CloudSEK's independent verification could not confirm this attribution.
CloudSEK suggests that PolinRider's documented credential harvesting capabilities are the most probable vector through which the npm maintainer account was compromised. The firm found no indication that any organization was successfully breached as a result of this specific attack. As of the report's publication, no official advisories had been issued by OSV, GitHub, or the package maintainer, although the malicious infrastructure remained active.
To mitigate the risks, CloudSEK recommends that developers pin their package dependencies to a known-good version, specifically advising against version 0.2.21 of @dforge-core/dforge-mcp. Any lockfile referencing this version should be treated as a potential indicator of compromise. The firm also suggests focusing on detecting the artifacts left by the payload chain rather than the implant itself. Additionally, monitoring for changes to a release workflow's trigger block, as was done in this attack, can provide an early warning of malicious activity.