Since August 2025, we’ve seen a wave of escalating supply chain attacks targeting the npm ecosystem. In this post, we break down three major incidents: S1ngularity, where an AI-generated workflow exposed secrets; the phishing of Qix, which showed how a single maintainer account could put millions at risk; and Shai-Hulud, the first self-replicating malware campaign. We close by examining what these attacks mean for Web3 security, what targets are most at risk, and how defenders should prepare for what’s coming next.

Week 1: S1ngularity (August 27, 2025)

S1ngularity began with a command injection vulnerability in an Nx GitHub Action generated by Claude AI. Attackers exploited the unsafe workflow to steal Nx’s NPM publishing token and then weaponized Nx’s popularity—around 6 million weekly downloads—as a distribution channel for malicious packages.

What the Attackers Achieved

The workflow’s access to privileged tokens gave attackers a direct path to compromise. Evidence indicates numerous developer credentials and tokens were exfiltrated, which were later used to publish malicious packages. Some of those stolen secrets provided the foothold for a sequel campaign that built directly on S1ngularity’s breach.

Why S1ngularity Stands Out

Supply-chain compromises weren’t new, but S1ngularity crystallized warnings that had been floating around for years:

AI-generated code can introduce critical vulnerabilities: The initial bug came from an AI-generated GitHub Action that slipped a command injection flaw into production.

Stolen credentials can fuel viral supply-chain attacks: Once attackers had Nx’s publishing token, they used it to compromise other projects and spread malware across the ecosystem.

AI-driven payloads can automate secret hunting: The malware payload included raw prompts (see diff in Nx issue #32523) for Claude, Gemini, and Q clients that instructed them to search for cryptocurrency wallets, and private keys. This turned local AI tools into exfiltration agents, targeting both developer credentials and crypto assets.

All three scenarios materialized here, faster than most expected, and set the stage for what followed.

Week 2: The Phishing of Qix (September 8, 2025)

Attackers phished Qix, a trusted maintainer, with a convincing 2FA reset email. Qix himself confirmed the compromise on Bluesky: “Yep, I’ve been pwned. 2FA reset email, looked very legitimate.” With his publishing rights in hand, adversaries pushed malicious updates under his name.

What the Attackers Tried

Like S1ngularity, it had a crypto-theft component, but this time the payload concentrated on Web3 frontends, aiming to drain wallets through the frontend itself instead of focusing on secrets from developer machines. It never reached scale, but the attempt revealed just how fragile the software supply chain remains. This time, the outcome turned more on luck than on resilient design.

What Worked for the Attackers

Permissive dependency ranges and automated CI/CD pipelines that blindly trust upstream dependencies began pulling the poisoned packages into production almost immediately. Even in the short window before the compromise was detected, updates propagated far enough to show how quickly a single maintainer account can put the ecosystem at risk.

What Saved Web3 Users

What prevented wide damage was a mix of luck, rapid detection, and existing good practices:

Narrow targeting: The payload was focused on crypto/Web3 frontends. It was designed to execute only in a user’s browser to intercept transactions. It failed to run in other environments like cloud servers or local developer machines, and it made no attempt to steal environment variables, exfiltrate API keys, or persist on an infected machine.

CI failures exposed the compromise: The malicious versions introduced fetch calls, which caused builds to break in older Node.js environments. These failures surfaced quickly and led to community reports, limiting the time the compromised packages remained live before npm removed them.

Locked dependencies: Few dApp frontends deployed new releases during that short exposure window. And where updates did occur, locked dependency versions prevented the malicious packages from ever being included in production builds. We explained in our previous post how locked dependencies stopped attacker code from reaching production frontends.

Week 3: Shai-Hulud (September 15, 2025)

Shai-Hulud was the first virus-like campaign in this wave of NPM compromises. Unlike Qix, which started with a single maintainer phishing, this campaign spread by seeding dozens of packages directly, most likely using authentication tokens stolen during S1ngularity. Over the course of several days, attacker published multiple revisions until it finally began to propagate across the npm registry as documented by Aikido Security.

Why Shai-Hulud Stands Out

S1ngularity showed how quickly stolen tokens could be weaponized, and Qix proved that a single phished maintainer could endanger millions of users. Shai-Hulud escalated the threat by attempting to replicate inside the ecosystem itself. The campaign demonstrated how attackers can iterate in real time, combining seeded packages with community spread, and how fragile NPM remains when malware is capable of modifying and re-publishing dependencies at scale.

Web3 Must prepare for Next Week

When we say “next week,” it’s not about the calendar; it’s about what comes next. We have observed a progression from secret-harvesting campaigns, to client-side crypto-drainers, and most recently, to attempts at self-replicating malware.

We expect that the coming wave will be optimized and more targeted. Instead of an autonomous self-replicating payload like Shai-Hulud, attackers can optimize the attack path to reach their targets while making less noise and delaying reaction by defenders.

A multipurpose multistage payload could harvest secrets to escalate access to critical cloud infrastructure and privileged blockchain private keys. We already know how dangerous that would be: the ByBit incident showed that a single exposed API key was enough to rewrite trusted frontend code and trigger one of the largest crypto heists in history.

Unlikely Web3 Targets

If the attacker’s objective is to obtain crypto funds, some systems are inherently less likely to be targeted. Generic, non-targeted malicious code tends to be detected quickly; attacks that must compromise software with long development and testing cycles are less attractive because the probability of detection is higher.

Smart contract code: Backdooring deployed smart contracts via a compromised npm package is theoretically possible given the heavy use of JavaScript tooling in development and deployment. However, this scenario is unlikely in practice: the chance of a successful, undetected compromise is low, while the probability of detection is high.

Wallet applications: To steal seed phrases or private keys, or to compromise key generation, the malicious packages would need to reach end users before the affected packages are detected, removed, and flagged. Wallet applications often release on cycles measured in weeks, while malicious packages inserted into the ecosystem typically survive only hours or a day or two before being detected and removed. This mismatch makes direct compromise of software wallets through widely used packages difficult and less likely.

Likely Web3 Targets

What past successful npm attacks already proved is simple: likely, the goal is to steal as many secrets as possible and turn them into access. Once obtained, these secrets can be used to mount follow-up attacks to steal crypto funds.

Our forward-looking read is that the next wave will be less noisy and more targeted. Instead of spraying malware across the ecosystem, attackers can focus on high-value secrets and specific environments, delaying detection while maximizing impact.

High-leverage targets include:

Release & infrastructure credentials: Tokens that let attackers publish software updates or web content directly. For example, package repository tokens, release-signing keys, CI service tokens, and other CDN or cloud API keys that can modify storage buckets or cloudfunctions.

dApp Frontends — Direct Deployments: dApp frontends often deploy several times per week. A compromised update can reach users almost immediately. In our previous research we measured dozens production deployments in about a seven-hour attack window; those builds stayed safe only because dependencies were pinned with lockfiles and the exposure window was short. A single compromised release can reach many users fast, and because attackers can convert a compromise into stolen funds almost immediately, frontends are a high-value, fast-payoff target.

dApp Frontends — Third-Party Scripts and Widgets: Many dApps load dynamic JavaScript code and chat components straight from third-party servers or CDNs like jsDelivr or unpkg without integrity checks. Because these scripts can change without any dApp rebuild, a single compromised release at the provider level propagates instantly. We study these external dependencies as part of our dApp Observatory research.

Trusted API Backends: Attackers can also target the APIs that wallets, dApps, and off-chain agents trust to build transactions. If these backends are compromised, they can change destination addresses or alter smart contract parameters to quietly redirect funds or manipulate protocol behavior. Examples include hacked routing services or price oracles feeding false data into DeFi systems.

What Comes Next

These campaigns were not isolated accidents. Attackers are probing, testing, and adapting in plain sight, and each wave has become more refined. The next compromise will likely be quieter, more targeted, and harder to detect. To prepare, teams should strengthen their supply chain defenses today, and we outline a practical guide in our companion post.