Ethersphere releases carried wallet-stealing malware

Both malicious versions in the bee-js malware incident went out through Ethersphere's release automation on November 10, 2026, according to The Hacker News. The maintainers attributed the releases to stolen continuous integration credentials and secrets.

Which Ethersphere releases were compromised?

The affected releases are @ethersphere/bee-js 13.3.0 and Swarm Desktop 0.56.2. An indirect npm installation could pull in bee-js, and a desktop update could bring the compromised app onto a machine.

The package table published by OX Security is reproduced below. Its Swarm Desktop release status and fix version differ from The Hacker News account. That discrepancy matters when choosing a desktop replacement: the table names 0.56.1, while the maintainer's incident note names 0.56.3.

The Hacker News and SC Media reported that both malicious releases had been removed. The maintainer's incident note identifies Swarm Desktop 0.56.3 as the clean replacement: the same code as 0.56.1, signed with a newly issued Developer ID certificate. The Hacker News compared the source and found only version-number and release-note changes. It also confirmed that npm had restored bee-js 13.2.0 as the latest version and that 13.3.0 was no longer available there.

The npm exposure window was short. According to The Hacker News, bee-js 13.3.0 was npm's latest version for about 75 minutes, from 00:09 to 01:25 UTC on November 10. Swarm Desktop 0.56.2 appeared on GitHub at about 00:36 UTC and remained available for about 8.5 hours before it was withdrawn.

The desktop updater could offer the malicious release to Windows x64 systems and Apple Silicon Macs within about 10 minutes, Socket found in analysis reported by The Hacker News. Intel Macs were never offered it. Linux installations do not update automatically.

According to The Hacker News, Socket estimated roughly 10 bee-js malware downloads, including scanners and mirrors. Swarm Desktop's recorded download count reached 65 by 08:27 UTC, including researchers. OX Security reported 44 desktop downloads before its publication. Downloads are not executions, though: none of those counts establishes how many machines actually ran the payload.

How the bee-js malware executes and steals wallet files

The npm payload runs from a postinstall script; the desktop payload runs whenever the affected app starts. The loader is the same in both releases, according to SafeDep's analysis reported by The Hacker News.

The loader fetches additional code from api.frameworkmetrics[.]xyz and runs it with the user's permissions. Unless disabled, npm installation scripts run automatically. An application did not need to import bee-js, call a library function, or start its own service for the downloader to run.

In bee-js, the downloader was tucked into the version-generation script. The added code sends the platform in the User-Agent header, includes X-Ethersphere: 1, and suppresses network errors. A successful-looking installation is therefore no assurance that the malware did not run.

Detection has another complication, identified by OX Security: requests with a missing or unsupported platform receive a benign-looking decoy script. A harmless response to an incomplete request proves only what that request received. It does not establish what the server returned to a supported victim sending the platform information the downloader was written to include.

The downloaded code looks in Swarm Desktop's data directory for config.yaml and data-dir/keys/swarm.key. If both files exist, it uploads them to the attackers. The key file is an encrypted Ethereum keystore. But its unlocking password is stored in plain text in config.yaml, alongside the material the payload is already looking for.

SafeDep says those files provide access to the node wallet's xDAI and xBZZ tokens, chequebook funds, and stake.

Checking bee-js dependencies and Swarm Desktop logs

I'd prioritize installation history over application imports when deciding which CI runners to investigate. The project's swarm-cli command-line tool, bee-dashboard package, and Swarm Desktop source all accepted dependency ranges that included 13.3.0. During the exposure window, a fresh installation could resolve to that bee-js malware release even though nobody had selected 13.3.0 explicitly.

Reviewing downstream bee-js packages

The following packages were identified by OX Security as direct or indirect dependency paths to the affected bee-js malware release.

1. Search lockfiles for @ethersphere/bee-js@13.3.0, including resolutions introduced through other packages.
2. Search package caches and internal registries for copies of the malicious version.
3. Review CI installation logs to establish which machines installed that resolution and whether installation scripts were enabled.

The GitHub advisory states: “Any computer that has this package installed or running should be considered fully compromised.” OX Security also cautions that installation does not necessarily mean the payload executed. For npm, the concrete condition is execution of the bee-js malware installation hook. A dependency-list entry alone does not establish that condition, even though the advisory calls for treating an installed package as a compromise.

Finding the Swarm Desktop launch marker

Search bee-desktop.log for Bee Desktop version: 0.56.2 (production). The affected version writes that exact line on every launch, immediately before executing the malicious code.

On macOS, search the app's log for that exact launch marker with this command:

grep 'Bee Desktop version: 0.56.2 (production)' "$HOME/Library/Logs/Swarm Desktop/bee-desktop.log"

SafeDep recommends treating any computer where Swarm Desktop 0.56.2 was installed as compromised.

Ethersphere backdoors survive package and app removal

The downloaded bee-js malware payload installs persistent remote access on Windows, macOS, and Linux. Updating bee-js or Swarm Desktop will not remove it. Neither will reinstalling or removing the affected package or app.

On Linux and macOS, the payload installs a Go remote shell called evjawbreaker in the hidden ~/.solidity/ directory. A user service keeps it persistent on Linux; a LaunchAgent does the same on macOS.

The Windows payload installs a genuine ScreenConnect client signed by ConnectWise. It runs as a system service and connects to the attackers' relay.

If the Windows user is an administrator, the code uses a known User Account Control bypass. Otherwise, it repeatedly displays the elevation prompt when the user cancels it. Once elevated, the code adds a Microsoft Defender exclusion and silently installs the ScreenConnect client, giving the payload its persistent remote-access service.

My concern on a developer laptop is the persistent backdoor, not only the node balance.

Searching Ethersphere network indicators

evjawbreaker reads its control-server address from that Ethereum contract, allowing the attackers to change the destination. The Hacker News reported that the contract was updated 29 minutes before the bee-js malware code was added. The address in the table is an observed control-server destination. It is not a fixed address built into the backdoor's operation.

Recovering Ethersphere hosts and Swarm node funds

1. From a clean computer, rotate every password, token, and key that the installing user or CI job could read.
2. If Swarm Desktop 0.56.2 ever ran, use a clean computer to move the node's funds, chequebook, and stake to a new key.
3. Where possible, rebuild the affected machine from a trusted image.
4. If cleaning in place, remove the applicable persistence artifacts listed above, including the hidden directory and platform-specific service or LaunchAgent.
5. Pin bee-js to 13.2.0.
6. Clear cached copies of 13.3.0, including copies in any npm mirror used for installation.
7. Install Swarm Desktop 0.56.3; replace the Linux package manually.

I'd rebuild an affected runner from a trusted image rather than rely on an in-place cleanup.

The maintainer's incident note says the desktop auto-updater will move 0.56.2 installations to 0.56.3.

Valid provenance did not stop the Ethersphere compromise

The malicious bee-js package had valid provenance. Ethersphere's real workflow built it, so the provenance correctly established the build's origin. It did not establish that anyone had reviewed the code being released.

Both releases came from bee-worker, Ethersphere's release-automation account. Neither malicious change was signed or went through a pull request. Creating a GitHub release for bee-js started an npm publishing workflow that required no approval. Socket reported that publication completed in 73 seconds.

Swarm Desktop's workflow exposed signing authority too, not just permission to publish a release. The attackers manually started a build workflow holding the project's Apple and Windows signing certificates. No approval was required there either. The resulting macOS app carried Ethersphere's Developer ID signature and Apple's notarization, so macOS displayed its normal first-launch prompt.

The maintainers have since limited app-signing jobs to the main branch and added DevOps-team approval. I'd require that approval boundary before release jobs can use GitHub Actions secrets with publishing or signing authority.

For projects that can tolerate delayed dependency updates, I'd consider OX Security's recommendation for a minimum package-age policy.

Socket linked this incident to the group behind earlier malicious Solidity extensions. Pluto Security had tied those extensions with high confidence to the original SleepyDuck group; the shared infrastructure included an Ethereum contract, a ScreenConnect relay, and filenames. Socket's analysis also indicated that a long-time maintainer's account was used alongside bee-worker.