Hackers Used Ethersphere’s Own Release Robot to Ship a Signed, Apple-Notarized Wallet Stealer, Proving a Valid Provenance Badge Isn’t a Security Check

Most companies treat a code signature, an Apple notarization stamp and a build-provenance record as proof that software is safe to install. A supply chain attack on Ethersphere, the team behind the Swarm decentralized storage network, shows how little those badges guarantee when the attacker controls the release pipeline itself. On November 9, 2026, intruders used the project’s own automation to ship a wallet-stealing loader and a cross-platform backdoor inside two official releases, and every trust signal checked out. Broadcom’s Symantec protection bulletin, published November 13, has now added the campaign to its threat coverage, and the full technical breakdown from supply chain security firm Socket reads like a checklist of what modern software verification does not catch.

What Happened

According to Socket, the attackers pushed two poisoned artifacts within roughly half an hour of each other. The first was @ethersphere/bee-js version 13.3.0, the JavaScript library behind Swarm Desktop and the swarm-cli command-line tool. It was the latest version on npm for about 75 minutes, from 00:09 to 01:25 UTC, before npm removed it, The Hacker News reported. The second was Swarm Desktop 0.56.2, labeled an “emergency patch release” on GitHub, which stayed public for about eight and a half hours.

Both releases came from bee-worker, the account Ethersphere uses to automate its releases, and neither change was signed or submitted as a pull request, per The Hacker News. Socket’s analysis indicates a long-time maintainer’s GitHub account was also used. In the note announcing the clean replacement, a maintainer wrote that 0.56.2 “was published by an attacker using stolen CI credentials and has been withdrawn.” How those credentials were stolen has not been explained.

Every Trust Signal Was Real

This is the part business leaders should study. For bee-js, the attackers simply created a GitHub release, which triggered the project’s legitimate npm publishing workflow. That workflow required no human approval and published the package in 73 seconds, according to Socket. Because the real workflow built it, the package carried valid SLSA provenance, the record that links an npm package to the repository and build that produced it. As The Hacker News put it, provenance shows where a package was built, not whether anyone reviewed the code inside it.

For the desktop app, the attackers manually started a build workflow that held the project’s Apple and Windows signing certificates and also needed no approval. The macOS build was signed with Ethersphere’s Developer ID and notarized by Apple, so users saw only the ordinary first-launch prompt. Socket found that the malicious change was tiny: comparing 0.56.2 with 0.56.1, only seven of 6,769 files in the app archive changed, and the only real code change was a 731-byte insertion into the app’s main process.

Distribution was then automatic. Swarm Desktop’s updater polls for new versions every ten minutes on macOS and Windows, so the poisoned build could reach Apple Silicon Macs and Windows x64 machines without anyone clicking a download link. Intel Macs were never offered the update, and Linux installs do not update automatically.

What the Malware Does

Both artifacts carried the same small loader, which fetches JavaScript from an attacker-controlled server and runs it with the user’s full privileges. In bee-js the loader runs as a postinstall script, meaning npm executes it during installation whether or not a project ever imports the library. In Swarm Desktop it runs every time the app starts.

• Wallet theft: the payload looks for the Swarm node’s config.yaml and its encrypted swarm.key keystore and sends both to the attackers. Because Swarm Desktop stores the keystore password in plain text in config.yaml, the pair can unlock the node wallet’s xDAI and xBZZ tokens, chequebook funds and stake, according to the reporting.
• Backdoor on macOS and Linux: a Go remote shell that installs in a hidden ~/.solidity folder and persists as a LaunchAgent or a Linux user service.
• Backdoor on Windows: a genuine, ConnectWise-signed ScreenConnect remote-access client installed silently as a system service, after the script bypasses or repeatedly re-shows the User Account Control prompt and adds a Microsoft Defender exclusion.

The backdoor reads its command-and-control address from an Ethereum smart contract used as a dead drop, so the operators can move their server without touching the malware. The Hacker News reported that the address had been updated just 29 minutes before the malicious bee-js code was added. Socket ties the contract, the controlling wallet and the implant files to the SleepyDuck/EtherDuck campaign that Pluto Security documented on October 1 in malicious Solidity extensions on the Open VSX marketplace.

How Big Was the Blast Radius?

Small, by luck rather than design. Socket’s rough estimate is that bee-js 13.3.0 was downloaded about 10 times, including by scanners and mirrors, and Swarm Desktop 0.56.2 had 65 downloads by 08:27 UTC, a figure that includes researchers, per The Hacker News. No theft of funds had been reported at the time of that coverage. Still, Ethersphere’s own swarm-cli, bee-dashboard and Swarm Desktop source accepted version ranges that included 13.3.0, so any fresh install in that window could have pulled the bad version in without anyone choosing it.

The project has since released Swarm Desktop 0.56.3, which the maintainer describes as the same code as 0.56.1 signed with a newly issued Developer ID certificate, and npm again lists 13.2.0 as the latest bee-js version. Ethersphere also changed its pipeline so signing jobs now wait for approval from its DevOps team and run only from the main branch. The GitHub advisory for bee-js 13.3.0 is blunt: “Any computer that has this package installed or running should be considered fully compromised.” Updating or uninstalling does not remove the backdoor.

Why It Matters for Business

The lesson is not about one niche crypto storage project. It is that the software supply chain’s newest defenses, from provenance attestations to notarization, verify the origin of a build, not its intent. If an attacker holds CI credentials, the pipeline will faithfully sign, attest and auto-deliver whatever they push. Three practical takeaways for any company that builds or consumes software:

• Gate the release robot. Any workflow that can publish packages or use signing certificates should require a human approval and run only from a protected branch, the exact controls Ethersphere added after the fact.
• Treat CI secrets like production keys. Rotate them, scope them narrowly and monitor automation accounts for releases that skip pull requests or signed commits.
• Slow down dependency intake. Pinning versions, using lockfiles, disabling install scripts in CI where possible and adding a short cooling-off period before adopting brand-new releases would have neutralized a package that was live for only 75 minutes.

Security teams should also note the recurring use of legitimate remote-access tools such as ScreenConnect as a backdoor; a signed, familiar binary is far less likely to trip alerts than custom malware.

The Bottom Line

The Ethersphere incident was contained quickly and appears to have hit few machines, but its playbook scales. Attackers no longer need to forge a signature when they can borrow the pipeline that produces real ones. For businesses, the defense is to put people and policy back between a commit and a customer’s machine, and to stop treating a green provenance check as a security review.

Sources: Socket; The Hacker News; Broadcom’s Symantec protection bulletin; Swarm Desktop changelog.

Edited by Coron @QUE.COM
Website: https://QUE.COM Intelligence
Sponsored by: https://MAJ.COM AI Autonomous