Ethersphere bee-js 13.3.0 and Swarm Desktop 0.56.2 compromised

What happened

Attackers used Ethersphere’s own release automation to publish two malicious releases: bee-js 13.3.0 and Swarm Desktop 0.56.2, according to The Hacker News. Both were published on 2026-11-09 UTC.

bee-js 13.3.0. StepSecurity reports the package was published to npm at 00:09:50 UTC. The release moved scripts/generate-version.cjs from the prepare hook to postinstall and added the scripts directory to the published files. The script requests /v1/analytics from api.frameworkmetrics[.]xyz and runs the response through JavaScript’s Function constructor with Node.js require and process. Importing the library is not required for this to run. Socket says this was the first install-time hook in the package’s npm history.

Swarm Desktop 0.56.2. Socket reports that all nine Linux, macOS and Windows packages came from one CI run and contain the same loader in the Electron main process. The macOS build was signed with the project’s Developer ID and notarized by Apple. The Hacker News reports it appeared on GitHub at about 00:36 UTC and was withdrawn about 8.5 hours later. Its auto-updater could offer it to Windows x64 and Apple Silicon Macs. Intel Macs were never offered it, and Linux installs do not update automatically.

What the payloads do. StepSecurity and The Hacker News agree on the main behavior:

• The downloaded code looks for config.yaml and data-dir/keys/swarm.key in the Swarm Desktop data directory. If both exist, it sends them to /v1/swarm/report on the attacker host.
• swarm.key is an encrypted Ethereum keystore. The Hacker News says Swarm Desktop stores its password in plain text in config.yaml, so both files together can give control of the wallet.
• On Linux, StepSecurity describes a downloaded executable in ~/.solidity/ and a user service named solidity-langsupport-runner.service. On macOS it describes a LaunchAgent named com.solidity.langsupport.runner.plist.
• On Windows, StepSecurity describes a script that stages launchers, adds a Microsoft Defender exclusion and silently runs an MSI. The Hacker News says this installs a genuine ScreenConnect remote-access client connecting to the attackers’ relay.
• StepSecurity statically inspected the Linux executables and found names associated with command execution and interactive shells. It did not run them. The Hacker News calls the Linux and macOS backdoor a Go remote shell named evjawbreaker. The macOS executable and the Windows invoke.ps1 and app.msi were not retrieved by StepSecurity, so their capabilities are not confirmed by that report.

How it got out. StepSecurity reports an unsigned direct commit under the bee-worker identity, titled like a normal release commit. The open release-please pull request #1288 was still unmerged. A GitHub release for v13.3.0 then triggered the existing trusted-publishing workflow. The package therefore carries valid SLSA provenance, which shows where it was built, not that the code was reviewed.

Where outlets differ on the credential. StepSecurity says the evidence points to misuse of the bee-worker identity and does not establish which credential was used or how it was obtained. Socket’s analysis indicates two GitHub accounts were compromised: bee-worker and a long-time maintainer account. Socket also describes a failed attempt on 2026-11-06 to harvest CI secrets and says it could not find evidence of exfiltration from that attempt (moderate confidence). The Hacker News reports that a maintainer’s incident note blames stolen CI credentials. How the credentials were stolen is not confirmed.

Attribution. Socket says the later stages use the same Ethereum contract (0xf8a900Db50b3331be6B768bA460BB59f3E40C344) and implant files documented earlier in an Open VSX campaign (SleepyDuck / EtherDuck), and says the same group is behind these releases. The Hacker News relays this and notes Pluto Security’s high-confidence tie between the earlier extensions and the original SleepyDuck. StepSecurity does not attribute the incident.

Scale and status. Not confirmed: the number of affected machines. StepSecurity notes its figure of 3,560 downloads across all versions for 2026-11-01 to 2026-11-07 predates the malicious release and is not a count of affected systems. The Hacker News reports a rough estimate of about 10 downloads of bee-js 13.3.0, including scanners and mirrors, and 65 downloads of Swarm Desktop 0.56.2 by 08:27 UTC, including researchers. It reports no theft of funds at the time of writing.

Takedown and fix. Socket says npm removed 13.3.0 about 75 minutes after publication. The Hacker News reports that 13.3.0 was the npm latest from 00:09 to 01:25 UTC and could no longer be downloaded when it checked. StepSecurity recorded npm still mapping latest to 13.3.0 at 00:31 UTC, which is consistent with that window. Maintainers withdrew Swarm Desktop 0.56.2 and released 0.56.3, which The Hacker News says is the 0.56.1 code signed with a newly issued Developer ID certificate. Its comparison found no changes beyond the version number and release notes.

Am I affected?

You may be affected if any of the following is true:

• A lockfile, package cache, internal registry or CI install log shows @ethersphere/bee-js@13.3.0, directly or as a transitive dependency. Per StepSecurity, swarm-cli 3.7.0 (^13.2.0), bee-dashboard 0.37.1 (^13.0.0) and the swarm-desktop repository (^13.0.0) all accepted ranges that allow 13.3.0. This does not mean those packages contain injected code; the resolved bee-js version is what matters.
• You ran Swarm Desktop 0.56.2. The Hacker News says the app log bee-desktop.log contains the line Bee Desktop version: 0.56.2 (production) at every launch. Log folders are ~/Library/Logs/Swarm Desktop/ on macOS, %LOCALAPPDATA%\Swarm Desktop\Log\ on Windows and ~/.local/state/Swarm Desktop/ on Linux.
• Install scripts were enabled during the install. A clean install log does not rule out execution, because the hook suppresses network errors (StepSecurity, The Hacker News).

You are not affected by this hook if you only used bee-js 13.2.0, which StepSecurity examined and found without the malicious install path. Blocking lifecycle scripts prevents the hook from running in future installs, but does not remediate an earlier execution.

What to do now

1. Search lockfiles, caches, internal registries and CI logs for @ethersphere/bee-js@13.3.0, including transitive copies. Pin a reviewed release such as 13.2.0 and clear cached copies of 13.3.0, including any npm mirror you install through.
2. Check DNS, proxy and endpoint logs for api.frameworkmetrics[.]xyz and the paths /v1/analytics, /v1/electron, /v1/assets/ and /v1/swarm/report, and for the header X-Ethersphere: 1.
3. Look for persistence: the ~/.solidity/ folder, the user service solidity-langsupport-runner.service on Linux, the LaunchAgent com.solidity.langsupport.runner on macOS, and the ScreenConnect Client (5cbe79c9c25524df) service on Windows (The Hacker News). Updating or removing the package or app does not remove these.
4. If the payload may have run, isolate the host, preserve evidence and rebuild from a trusted image rather than cleaning in place (StepSecurity, The Hacker News).
5. From a clean computer, rotate every password, token and key that the installing user or CI job could read.
6. If Swarm Desktop wallet files were present, treat the keystore and the password in config.yaml as exposed. Per The Hacker News, move the node’s funds, chequebook and stake to a new key from a clean computer.
7. Install Swarm Desktop 0.56.3. On Linux, replace the package by hand.

Sources

• StepSecurity: @ethersphere/bee-js 13.3.0 Compromised
• Socket: Malicious bee-js npm Release and Swarm Desktop Releases Deliver SleepyDuck Ethereum C2 Backdoor
• The Hacker News: Hackers Compromise Ethersphere’s bee-js and Swarm Desktop to Deliver Wallet-Stealing Malware