Attackers Hijacked Ethersphere’s Own Release Pipeline to Ship Signed, Wallet-Stealing Swarm Desktop and bee-js Updates

For roughly eight and a half hours on Monday, the official desktop app for the Swarm decentralized storage network handed its own users a backdoor. Attackers used Ethersphere’s own release automation to publish malicious versions of two of the project’s tools, the @ethersphere/bee-js JavaScript library (version 13.3.0) and the Swarm Desktop app (version 0.56.2). Both were built by the project’s real workflows, and the desktop build carried the project’s genuine code-signing certificates, according to reporting by The Hacker News and analyses from supply chain security firms Socket, SafeDep and OX Security.

The download numbers look small. The lesson does not. This is a clean example of an attack that passes every automated trust check a modern software team relies on, and it is worth understanding even if your company has never heard of Swarm.

What Happened, Hour by Hour

Per The Hacker News, citing Socket’s incident analysis, the poisoned bee-js 13.3.0 was the latest version on npm for about 75 minutes, from 00:09 to 01:25 UTC on November 9. Its malicious code ran as a postinstall script, which npm executes automatically during installation unless install scripts are disabled, so a project did not even have to import the library to be hit. Ethersphere’s own swarm-cli and bee-dashboard packages accepted version ranges that included 13.3.0, meaning a fresh install in that window could have pulled it in indirectly.

Swarm Desktop 0.56.2 appeared on GitHub at about 00:36 UTC and was withdrawn roughly 8.5 hours later. Socket found that the app’s built-in updater could offer it to Windows x64 computers and Apple Silicon Macs within about 10 minutes. Intel Macs were never offered it, and Linux installs do not update automatically.

No report gave a count of infected machines. 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 reached 65 downloads by 08:27 UTC, including researchers. OX Security notes that the affected components together see more than 16,800 monthly downloads across direct and indirect dependencies. No theft of funds had been reported at the time of The Hacker News’ writing.

What the Malware Was After

According to SafeDep’s technical analysis, both releases carried the same small loader that fetched more code from an attacker-controlled server and ran it with the user’s permissions. That code looked for two files in Swarm Desktop’s data folder: the node’s encrypted Ethereum keystore and a config file. The catch is that Swarm Desktop stores the keystore’s password in plain text in that config file, so stealing both effectively hands over the node wallet’s xDAI and xBZZ tokens, its chequebook funds and its stake.

The payload also planted persistent remote access. On Linux and macOS it installed a Go remote shell that reads its command server’s address from an Ethereum smart contract, letting the attackers change it at will. On Windows it installed a genuine, vendor-signed ScreenConnect remote-access client running as a system service, after using a known User Account Control bypass and adding a Microsoft Defender exclusion. Socket links the operation to the same group behind earlier malicious “Solidity” developer extensions on the Open VSX marketplace.

Why “Signed and Verified” Was Not Enough

Both releases came from bee-worker, the account Ethersphere uses to automate releases, and neither change was signed or submitted as a pull request. For bee-js, publishing a GitHub release triggered an npm publishing workflow that needed no approval and shipped the package in 73 seconds, Socket found. Because the project’s real workflow built it, the package carried valid npm provenance, which proves where a package was built, not whether anyone reviewed what is inside.

For Swarm Desktop, the attackers manually started a build workflow that held the project’s Apple and Windows signing certificates and also required no approval. The macOS build was signed and notarized by Apple, so users saw only the normal first-launch prompt. Ethersphere’s maintainers wrote that 0.56.2 “was published by an attacker using stolen CI credentials,” and they have since made signing jobs wait for DevOps approval and run only from the main branch. How the credentials were stolen remains unclear.

Why It Matters for Business

Most companies now treat a code signature, an app-store notarization or a provenance badge as a proxy for “safe.” This incident shows those signals only confirm that a build came from the expected pipeline. If an attacker holds the keys to that pipeline, every signal turns green for them too. The weak point was not the code; it was a release process that let a single automation account publish and sign software with no human in the loop.

It also joins a string of recent attacks, covered here on Que.com, in which a trusted update channel was turned into a malware delivery system, including poisoned updaters in the gaming and server-security worlds. Auto-update is a feature customers love, and attackers have noticed that it is also the fastest way to reach thousands of machines with a file nobody will question. For any business that ships software, or runs CI pipelines that pull open-source packages, the practical questions are simple: who can trigger a release, which jobs can touch signing keys, and does any of that require a second person to approve?

What Defenders Should Do Now

• Search lockfiles, package caches, internal registries and CI logs for @ethersphere/bee-js@13.3.0, pin 13.2.0 and purge cached copies. The GitHub advisory says any computer that installed or ran it “should be considered fully compromised.”
• Swarm Desktop users should check the app log for version 0.56.2, update to the clean 0.56.3 (Linux packages must be replaced by hand) and, if 0.56.2 ever ran, move the node’s funds, chequebook and stake to a new key from a clean computer.
• Updating or uninstalling does not remove the backdoor. Researchers advise rebuilding affected machines from a trusted image and rotating every password, token and key the user or CI job could read.
• More broadly, require human approval for release and signing workflows, restrict them to protected branches, and disable npm install scripts in CI where you can.

The Bottom Line

The Ethersphere compromise was caught quickly and likely touched few machines, but it is a near-perfect template for the next big supply chain attack: steal a pipeline credential, let the real build system do the signing, and let auto-update do the distribution. Treat your release automation like production infrastructure, with approvals, least privilege and monitoring, because attackers already do.

Sources: The Hacker News, OX Security, with analysis from Socket and SafeDep as cited by The Hacker News.

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