GHAPPIER Supply Chain Attack Poisons npm Package, Compromises 65 GitHub Repos

Key Takeaways

• A supply chain attack, dubbed GHAPPIER, compromised 65 GitHub repositories and infected 73 files across 22 accounts.
• The attack leveraged a legitimate npm package, @dforge-core/dforge-mcp, to distribute a malicious remote code loader.
• Attackers gained access to a package maintainer account, altered source code, and automated the publication of a malicious version (0.2.21) via GitHub Actions.
• The malicious package was digitally signed with valid npm provenance, highlighting a critical flaw where repository write access can bypass trusted publishing safeguards.
• The attack chain involved a multi-stage loader with a self-deleting final component, and researchers linked a secondary payload to the PolinRider campaign, which uses Ethereum blockchain for C2.

A sophisticated software supply chain attack, identified as GHAPPIER, has exposed vulnerabilities in trusted development processes, demonstrating how quickly a legitimate maintainer account can become a conduit for malware. This operation successfully compromised 65 GitHub repositories, affecting 73 files across 22 distinct accounts by injecting a malicious loader through a seemingly benign npm package.

The attackers exploited their access to a package maintainer’s account to modify the source code and automate the publication of a malicious version directly from the project’s main branch. This method allowed the poisoned release to appear legitimate, as it was built and distributed through the project’s established automated publishing pipeline. Consequently, a routine dependency update could inadvertently introduce a remote code loader into unsuspecting developer environments.

According to CloudSEK said in a report, the incident commenced on September 9, when an unauthorized individual maintained control of the @dforge-core/dforge-mcp package for 105 minutes. While the exact method of initial access remains unconfirmed, researchers speculate that a compromised developer machine, browser extension, or another infected package could have facilitated the theft of credentials. This event underscores the critical need to view trusted publishing, source control access, and developer endpoints as interconnected components within a unified security perimeter.

The GHAPPIER attack also highlights a concerning trend where malicious GitHub workflow campaigns are weaponizing automation to facilitate credential theft and broader repository compromise.

GHAPPIER Supply Chain Attack Details

During the compromise, the threat actor surgically inserted a remote loader into the package. They then modified three lines of code to trigger a release workflow upon pushes to the main branch and subsequently rewrote that workflow to enable unattended publication. The malicious @dforge-core/dforge-mcp version 0.2.21 was available as the latest registry release for 35 minutes and 38 seconds before the legitimate maintainer intervened, restored the project, and released a clean version 0.2.22.

A particularly alarming aspect of this attack is that the manipulated package bore valid npm provenance. It was created using GitHub Actions with OpenID Connect trusted publishing, and its attestation in Sigstore recorded the attacker’s commit. This demonstrates that even with robust provenance mechanisms, write access to a repository can effectively translate into publishing access, a risk previously observed in large-scale npm package compromises. The presence of valid provenance did not guarantee the safety of the code entering the build process.

The embedded loader was cleverly concealed within a single line near line 3,320 of a 99 KB file, initiating a sophisticated four-stage attack chain. The final stage of this chain was designed to self-delete, significantly reducing the likelihood of detection through conventional disk searches. Despite its removal from the npm registry, researchers confirmed that all stages of the loader remained active and responsive five days after the malicious package was withdrawn.

Hidden Delivery Chain Raises Response Risks

CloudSEK’s comprehensive investigation uncovered a second payload family in another compromised repository, linking it to the known PolinRider campaign. PolinRider is notorious for silently appending malicious code to legitimate project configuration files. Uniquely, this payload retrieves its command-and-control (C2) information from an Ethereum blockchain transaction, bypassing traditional domain or hostname-based C2 infrastructure. The research noted that an exact match of this beaconing behavior was still active at the time of their report.

Researchers suggest that this observed pattern could provide insight into how the initial account takeover occurred. The PolinRider campaign is known for harvesting cached Git credentials from infected machines, allowing attackers to push malicious code under the guise of a legitimate developer. This scenario underscores the critical importance of robust endpoint protection for developer machines, which is as vital as stringent repository review processes, especially given recent incidents where private repositories were exposed due to token-stealing supply chain attacks.

What You Should Do

• Pin Package Version: Immediately pin the @dforge-core/dforge-mcp package to version 0.2.22 in your projects.
• Review and Scan: Conduct a thorough review to determine if version 0.2.21 of the package was installed or executed within your environment. Implement comprehensive scans for its presence.
• Block IoCs: Block all identified socket endpoints and delivery hostnames associated with the attack, as detailed in the full research report.
• Search for Artifacts: When searching for compromise, prioritize looking for artifacts left by the entire attack chain, not just the self-deleting implant.
• Audit Release Workflows: Perform an audit of all release workflow changes in your GitHub repositories.
• Restrict Main Branch Access: Implement stricter controls on write access to main branches in your repositories.
• Rotate Credentials: Promptly rotate any credentials that may have been exposed during the attack.
• Preserve Logs: Ensure all source-control logs are preserved for forensic analysis.
• Enhance Endpoint Security: Strengthen endpoint protection on developer machines, as these are frequent targets for initial access in supply chain attacks.
• Implement CI/CD Monitoring: Pair package integrity checks with continuous monitoring of CI/CD activity and developer accounts to detect anomalies.

Indicators of Compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.