Ethersphere npm Supply Chain Attack Turns a Release Bot Into a Wallet Thief
- Who should care: Swarm node operators, bee-js users, and any team that treats npm provenance as proof of safety after the Ethersphere npm supply chain attack.
- What could go wrong: Stolen wallet keys and backdoors that survive reboots.
- Do this: Search lockfiles for bee-js 13.3.0 and Swarm Desktop 0.56.2. Found either? Rebuild the machine and move funds to a fresh wallet.
- Worth remembering: Provenance tells you who built a package. What’s inside is still your problem.
Introduction
A routine version bump turned into a wallet heist early Monday. The Ethersphere npm supply chain attack pushed a poisoned release that passed every provenance check, then quietly stole Swarm node keys and planted backdoors on three operating systems. It is a textbook supply chain attack, with one twist: the package came with a valid receipt.
What Happened?
At 00:09 UTC on November 9, version 13.3.0 of @ethersphere/bee-js landed on npm. It came from the project’s own release bot account, which researchers believe was compromised. An unsigned commit skipped the open release pull request, a GitHub release triggered the normal publish workflow, and the package shipped with valid SLSA provenance.
Two quiet edits did the damage in the Ethersphere npm supply chain attack. A version script moved to postinstall, and the scripts folder got packed into the tarball. About 30 minutes later, the same loader showed up in Swarm Desktop 0.56.2, billed as an emergency patch.

Why Every Check Said Yes
Provenance proved the real pipeline built the package. It never claimed the source was honest. And the server handed its real payload only to requests carrying a special header; everyone else got a decoy.
Once installed, the payload grabbed config.yaml and swarm.key from the Swarm Desktop folder and posted both to the attacker. That config can hold the keystore password in plain text, putting wallet funds and stake in play. Then it dug in:
- Linux and macOS: a Go remote shell under
~/.solidity/that finds its server through an Ethereum smart contract - Windows: a genuine, signed ScreenConnect client rewired to the attacker’s relay, running as SYSTEM

What’s the Impact of the Ethersphere npm Supply Chain Attack?
npm pulled 13.3.0 roughly 75 minutes after it went live. That stops new installs, not old infections. Downstream tools with loose caret ranges, like swarm-cli and bee-dashboard could have resolved the bad version.
Like the trusted vendor script behind earlier incidents, the code arrived through a channel everyone already trusted. Any machine that ran it should be treated as owned.
How to Avoid This
- Pin dependencies and review lockfile diffs for newly added install scripts
- Block lifecycle scripts by default in CI and on developer machines
- Limit who can cut GitHub releases, and require signed commits on release tags
- Hold brand new package versions in a cooldown before they reach builds, and use staged publishing on npm where you can
- Treat provenance as one signal, never as the verdict
Researchers at SafeDep and StepSecurity have published full technical breakdowns. The pattern maps directly to OWASP A08:2025 Software or Data Integrity Failures.
Indicators of Compromise
The visual below includes hashes, hosts, persistence paths, and the C2 contract for the Ethersphere npm supply chain attack. The full list of historical hubs and payload hashes is in the researchers’ IOC file.

Your Pipeline Trusted It. Somebody Should Have Tested It.
Every check in the Ethersphere npm supply chain attack said yes because every check asked the wrong question. Secure.com’s AI teammates attack your build path the way an intruder would, harden what they find, and prove the fix held, while your team sets the rules.
- AppSec Teammate flags lockfile changes that add install scripts before they reach a build
- Red Teammate tests who can actually publish from your repos and what a stolen bot token could reach
- SOC Teammate ties odd DNS lookups and new remote access tools into one case
- Big moves, like yanking a package or isolating a host, wait at your approval gate with a record of who decided
- No more lockfile archaeology at 2 a.m.