Attackers exploited a maintainer account for just 105 minutes to distribute a previously unknown malware loader called GHAPPIER through a legitimate npm package, shipping a malicious release that carried valid provenance despite its dishonest source. CloudSEK detailed the supply chain attack in a report published September 20, describing how someone took control of the maintainer account for @dforge-core/dforge-mcp on September 9. The attack highlighted a fundamental gap in trusted publishing: cryptographic attestation verifies where software was built, but can't detect when the underlying source code has been compromised.
The intruder released two malicious versions in rapid succession, according to the report. A first attempt, version 0.2.20, failed and broke the package installation. Version 0.2.21 successfully delivered the loader and remained the current release for 35 minutes and 38 seconds before withdrawal. The attacker had already gained push access to the main branch through means CloudSEK couldn't definitively establish, though the firm suspects a developer machine infected by a malicious extension or package. To enable the attack, the intruder modified three lines of code so any push to the main branch would trigger the release workflow, then rewrote the workflow 14 minutes later to allow unattended publishing. The build executed through GitHub Actions with OIDC trusted publishing, and its attestation remains visible in Sigstore's public log, naming the attacker's commit. The malicious code consisted of a single line embedded in a 99KB file that initiated a four-stage chain ending in a general-purpose remote shell which erased itself from disk while running. It activated when the MCP server launched rather than during installation, meaning systems that installed version 0.2.21 without starting it never executed the loader.
"Provenance attests where an artefact was built, not whether its source was honest," CloudSEK stated. Because the registry places trust in the repository's CI identity, push access effectively became publish access, and the release passed npm audit signatures without triggering alerts. The firm emphasized that no exploitation of GitHub, npm, or any package occurred. "Every action in this report is an authorised action taken with a stolen key," the report noted. CloudSEK traced GHAPPIER across at least 65 public repositories, 73 infected files, and 22 accounts. A second payload discovered in another victim's repository matched exactly with PolinRider, a campaign OpenSourceMalware has monitored since March 2026. That payload retrieved its configuration from an empty Ethereum transaction costing roughly $0.20, leaving no domain to suspend or host to seize.
The attack exposes a critical vulnerability in the trusted publishing model that many open-source ecosystems have adopted to strengthen supply chain security. The report explains that because the registry trusts the CI system's identity rather than validating the integrity of source commits, any attacker with repository access can publish packages that appear fully legitimate to automated security checks. CloudSEK identified PolinRider's documented credential harvesting as the most likely entry point for stealing the maintainer account credentials. Other researchers have attributed PolinRider to North Korea, though CloudSEK said its independent verification didn't confirm that connection. As of the report's publication, no advisory had surfaced in OSV, the GitHub database, or from the maintainer, even though every stage of the attack chain still responded five days after the malicious version was withdrawn. CloudSEK found no evidence that any organization suffered a successful compromise.
CloudSEK recommended pinning the package at version 0.2.22, treating any lockfile that pins 0.2.21 as an indicator of potential compromise, and scanning for the artifacts the attack chain leaves behind rather than searching for the implant itself. The firm also urged developers to set up alerts for changes to a release workflow's trigger block, which in this incident came 14 minutes before the workflow gained publishing capability. The brief window of exposure and the attacker's swift execution underscore how quickly supply chain attacks can propagate through trusted infrastructure once credentials are compromised. Organizations relying on provenance alone may discover they're validating the wrong question—not whether the build process was legitimate, but whether the code entering that process was ever trustworthy. The gap between technical attestation and actual security creates an opening that credential theft can exploit with devastating efficiency, turning the very systems designed to protect software distribution into vehicles for delivering malware.