Supply Chain Attack Unveils Malicious GHAPPIER Loader in npm Package
In a significant breach of software security protocols, attackers exploited npm trusted publishing in a supply chain attack that resulted in the distribution of a previously unknown malware loader called GHAPPIER. This loader was surreptitiously included in a legitimate npm package, which was released with valid provenance, showcasing the alarming vulnerabilities in package management systems.
According to a report published by CloudSEK on September 20, a maintainer account associated with the package @dforge-core/dforge-mcp was compromised for a duration of 105 minutes on September 9. During this brief window, the attackers managed to execute two malicious releases. The first release, version 0.2.20, was ineffective and disrupted installation for users. However, the subsequent version, 0.2.21, successfully deployed the GHAPPIER loader and remained the latest available version for approximately 35 minutes and 38 seconds before it was identified and withdrawn.
CloudSEK was unable to determine the method by which the attacker gained access to the maintainer account, though there are suspicions that a developer’s machine might have been compromised by a malicious browser extension or software package. This incident highlights the vulnerabilities that exist when individuals or organizations do not maintain strict protections on their development environments.
Dissecting the Attack Mechanism
The report unraveled the attack’s intricacies, revealing that the attacker made minimal yet consequential alterations to the package’s code. Specifically, three lines of code were tweaked, allowing any push to the main branch to initiate the release workflow. Just 14 minutes later, the attacker rewrote the workflow to enable unattended publishing. This procedure was facilitated through GitHub Actions employing OpenID Connect (OIDC) trusted publishing, showcasing that the attack maintained legitimate signatures in the npm registry’s audit process. As articulated by CloudSEK, the ability to track the provenance of the package’s build does not equate to the assurance that its source is trustworthy. The npm registry’s trust in the original repository’s CI identity erroneously permitted push access to be considered equivalent to publish access.
The loader itself was ingeniously disguised within a one-line code fragment embedded in a 99KB file and initiated a four-stage chain, culminating in a versatile remote shell. Notably, the loader did not execute upon installation of version 0.2.21 but rather upon the launch of the MCP server. As a result, systems that installed the malicious version without subsequently running the server did not trigger the loader.
In a crucial finding, CloudSEK stated that they discovered no exploitation incidents associated with GitHub, npm, or any other packages. The report emphasized that every action discussed was an authorized operation perpetrated using a stolen authentication key.
Linking GHAPPIER to Wider Threat Networks
Further investigation led CloudSEK to link the GHAPPIER loader to at least 65 public repositories, 73 infected files, and 22 distinct accounts. The report identified a second payload that closely mirrored PolinRider, a campaign that OpenSourceMalware has been monitoring since March 2026. Notably, this second payload utilized a unique method of reading its configuration from an empty Ethereum transaction that only incurred a nominal cost of about $0.20, effectively sidestepping traditional tracking mechanisms that could lead to the seizure of domains or hosts.
While some researchers have tentatively attributed PolinRider to North Korea, CloudSEK indicated that their independent verification did not provide conclusive evidence to confirm this association. Still, the documented credential harvesting tactics employed by PolinRider are believed to be the most plausible vector for the compromise of the maintainer account in this case.
As of the date of the report, there had been no alerts issued regarding this incident by either OSV, the GitHub vulnerability database, or the original package maintainer. Even days after the malicious releases were retracted, the stages of the attack remained responsive, signaling a need for ongoing vigilance.
Recommendations for Developers
In light of these revelations, CloudSEK has issued several recommendations for developers to safeguard against potential future assaults. They advised pinning the vulnerable package at version 0.2.22 to prevent unintended use of version 0.2.21. Additionally, any lockfiles that reference the latter version should be treated as indicators of compromise. Developers are also urged to conduct thorough sweeps for artifacts left by the attack’s chain, rather than solely searching for the implant. Lastly, the report advises heightened alertness to any modifications in a release workflow’s trigger blocks, especially when such changes occur just minutes prior to the commencement of automated publishing.
These recommendations serve as a crucial reminder of the vulnerabilities associated with software supply chains and the continuous need for developers to implement strong security measures to protect their environments and contributions.