Learnings from recent npm supply chain compromises

Overview

There has been a recent surge in successful, large-scale supply chain attacks, with three incidents compromising a combined total of more than 500 npm packages. Attackers continue to target the software supply chain, and each successful breach underscores the need to test our defenses and strengthen security practices where they fall short.

What happened

s1ngularity (August 26, 2025)

The s1ngularity attack targeted Nx, a popular build system, through various Nx npm packages. The attackers gained access by exploiting a vulnerability in the pull_request_target trigger in the GitHub Actions workflow, which allowed them to steal an npm publishing token for the Nx packages. With this token, they published malicious versions of the packages to the npm registry.

Each compromised package contained a credential-harvesting malware script called telemetry.js, which executed as a post-install script on Linux and macOS systems. Once active, the malware systematically searched infected machines for sensitive data. The attackers then exfiltrated the stolen data to newly created, public GitHub repositories under the victims’ own accounts, using a consistent naming convention like s1ngularity-repository.

In the attack’s second phase, the stolen GitHub tokens were used to change thousands of private repositories to public, exposing even more data and secrets. In total, researchers confirmed that over 2,000 unique secrets were leaked during the initial phase, with the secondary exposure compounding the damage across thousands of repositories.

For more information on s1ngularity, check out the GitHub security advisory or Nx’s post mortem.

debug/chalk (September 8, 2025)

Attackers breached a high-profile npm maintainer known as Qix through a sophisticated phishing campaign. Using a fraudulent domain, support@npmjs[.]help, the attackers imitated a two-factor authentication (2FA) reset email to gain initial access to several popular packages, including debug, chalk, and ansi-styles.

The attackers injected obfuscated, browser-based malware into more than 18 npm packages. The malicious code functioned as a crypto stealer, hooking browser APIs to hijack cryptocurrency transactions by silently replacing wallet addresses with attacker-controlled ones.

Although the malicious versions were downloaded more than 2.5 million times, the impact was minimal as it is reported that only $500 was stolen. Still, the incident reinforced how one compromised account can ripple across the software ecosystem, and how phishing remains one of the most effective entry points for large-scale supply chain attacks.

For more information, you can follow the investigation in the debug GitHub issue.

Shai-Hulud (September 16, 2025)

The Shai-Hulud attack came just three weeks after the s1ngularity incident and is believed to have been carried out by the same group. The attackers exploited unrotated tokens left over from the s1ngularity breach to gain access to additional npm projects via a self-replicating worm, which further extended their reach.

Once inside, the attackers used GitHub Actions workflows to exfiltrate secrets from compromised repositories and send them to webhook[.]site. They also migrated private repositories to public, appending “-migration” to the repository names. This not only exposed sensitive data but also disrupted development workflows for thousands of affected projects.

This campaign demonstrated how quickly attackers can pivot after an initial compromise, using valid tokens and automated CI/CD workflows to scale their impact. It underscored the importance of immediate credential rotation after an incident.

To read more about this attack, check out Socket’s report.

Key learnings

Attack vectors

CI/CD workflows

GitHub Actions workflows played a central role in both the s1ngularity and Shai-Hulud attacks. In the s1ngularity attack, the attackers gained initial access using Github Actions by injecting executable code into a pull request workflow. In the Shai-Hulud attack, they used GitHub Actions to exfiltrate secrets from compromised repositories, sent them to webhook[.]site, migrated private repositories to public, and appended -migration to their names. The scale of these attacks underscores the importance of securing CI/CD workflows.

The s1ngularity breach was not the first time attackers exploited the pull_request_target trigger to execute arbitrary code in a CI/CD workflow. This class of vulnerabilities, often called “pwn requests,” allows attackers to gain elevated repository permissions through a GITHUB_TOKEN or to exfiltrate repository secrets. On October 3, researchers published additional findings showing that two other popular npm projects, cross-fetch and GraphQL-JS, contained a similar underlying flaw to Nx. Until dependencies stop running untrusted pull request code in GitHub Actions workflows that handle secrets, we can expect to see more supply chain compromises of this kind.

These npm pwn request incidents are not the only recent examples of attackers targeting GitHub Actions. On September 2, 2025, a separate campaign known as GhostActions leveraged a compromised PyPI maintainer account to insert a malicious GitHub Actions workflow. The workflow was designed to steal secrets from the Actions environment, and researchers later confirmed that it exfiltrated more than 3,000 secrets, including npm tokens that could be used in subsequent supply chain attacks.

Hardening GitHub Actions workflows would not have contained the spread seen in the Nx incident, but these measures can help prevent similar exploitation in your own environment. GitHub provides detailed security best practices in its documentation, and Wiz has also published guidance on securing and minimizing the attack surface of GitHub Actions.

Phishing

Phishing also continues to serve as a reliable path for initial access. In the debug/chalk incident, an experienced developer fell victim to a phishing email disguised as an npm 2FA reset request. This was not the first npm-related phishing campaign: In July 2025, attackers spoofed an npm site to target developers through a typosquatted domain. These incidents reinforce the reality that breaching a single npm account can cascade into the compromise of dozens, even hundreds, of packages.

Targets

Long-lived credentials remain prime targets in supply chain attacks because of the access and information they provide. But even when organizations recognize this risk, rotating tokens consistently remains a challenge. Large, distributed development environments often rely on numerous long-lived credentials, such as API keys, personal access tokens, and service account tokens, that are hard to track and even harder to replace without disrupting critical workflows. Attackers exploit these operational gaps, turning overlooked credentials into powerful entry points.

Where possible, fine-grained access tokens offer a stronger defense than traditional personal access tokens, because their limited scope reduces the attack surface in the event of a compromise. These tokens let teams configure permissions to grant only the minimum access required. Multi-factor authentication (MFA) strengthens account security by adding additional verification steps to prevent attackers from easily exploiting stolen credentials, even if a token or password has been leaked. Although fine-grained access tokens should be used whenever possible, enabling MFA helps secure accounts in scenarios where token-based authentication is not an option.

Cryptocurrency continues to attract attackers in supply chain incidents because it offers fast, high-value payouts that are difficult to reverse or trace. Stolen cryptocurrency can be quickly diverted, making recovery nearly impossible. The lure of untraceable profits ensures that crypto remains frequent targets for malicious actors seeking both financial gain and persistence within the software ecosystem.

Retrospective

What went wrong?

After the s1ngularity attack, tokens were not properly rotated, and researchers believe this lapse created the initial access vector for the Shai-Hulud attack. Additionally, npm responded slowly to remove the vulnerable package versions from its registry.

Phishing emails have also grown more sophisticated, aided by the widespread availability of AI tools. As a result, even highly experienced developers have fallen victim to these attacks.

What went right?

Security researchers, npm maintainers, and GitHub acted quickly to limit the impact of the incidents. GitHub disabled the newly created repositories to limit data exposure. Although npm was slow to remove the vulnerable packages, Nx acted quickly to publish security fixes to contain the spread of the malicious versions. Knowledge sharing also played a key role in the response: Blog posts and advisories published soon after the incident helped spread awareness and gave developers concrete ways to investigate potential compromise.

Naming conventions in both the s1ngularity and Shai-Hulud attacks also aided investigators. In the first attack, researchers could search for accounts with repositories containing s1ngularity-repository. In the latter, GitHub queries allowed users to check their repositories against Shai-Hulud Migration in the description and -migration added to the repository name.

How can we improve for next time?

Two alternative Javascript package managers, pnpm and yarn, have introduced an option to enforce a minimum package age. This setting creates a buffer when dependencies are pinned to the latest version of a package, reducing the likelihood of immediate compromise. If adopted widely, this feature could significantly decrease the success rate of supply chain attacks. As of the publication of this post, npm has yet to add this option.

According to GitHub, which owns the npm registry, the platform is undergoing a series of hardening measures to improve security. The team plans to limit publishing options to three methods: 2FA, granular access tokens with a seven-day lifetime, and trusted publishing. GitHub is taking 2FA a step further by moving npm maintainers to FIDO-based 2FA and phasing out time-based one-time passwords (TOTP) 2FA. These changes will roll out gradually to give maintainers time to update their existing workflows.

How Datadog can help

Datadog Code Security customers can use the Software Composition Analysis (SCA) product to identify any services that contain compromised npm packages. Reviewing emerging threats from Datadog’s Security Research team helps quickly identify at-risk projects.

Customers can also use the Static Code Analysis (SAST) product to identify vulnerabilities in GitHub Actions, using two rules specifically designed to detect script injection through user controlled values and dangerous GitHub Actions triggers. These rules could have caught the vulnerability in passports.js that led to the initial s1ngularity attack and can help protect your company from similar attacks. Running this query checks your code for those vulnerabilities, helping you identify similar risks in your systems and take action before attackers can exploit them.

Datadog has released two different open source tools that can help prevent supply chain attacks: GuardDog and Supply-Chain Firewall. GuardDog is a Python-based CLI tool that analyzes metadata and heuristics to flag malicious packages. It can scan local or remote PyPI and npm packages, Go modules, GitHub Actions, and even VSCode extensions. Supply-Chain Firewall, another Python tool, prevents the installation of malicious or vulnerable npm and PyPI packages. Its goal is to protect developer workstations from compromise and stop supply chain attacks before they reach production.