Ethersphere supply chain attack steals Swarm wallet keys via CI compromise

On November 9, 2026, attackers compromised the release automation of the Ethersphere project to distribute malware through two of its core tools. The incident targeted the Swarm decentralized storage network by injecting malicious code into bee-js version 13.3.0 and Swarm Desktop version 0.56.2. These compromised releases were designed to steal private wallet keys and install persistent backdoors on Windows, macOS, and Linux systems before being withdrawn hours later.

What happened

The attack leveraged the project’s own continuous integration (CI) infrastructure, specifically an account named bee-worker used for automated releases. Attackers published a GitHub release for bee-js 13.3.0, which triggered the project’s npm publishing workflow without requiring manual approval. This process generated valid provenance records, making the package appear legitimate despite containing malicious code. The package remained available on npm for approximately 75 minutes, from 00:09 to 01:25 UTC, during which it was downloaded roughly 10 times, primarily by security scanners and mirrors.

Simultaneously, the attackers manually initiated a build workflow for Swarm Desktop 0.56.2 that had access to Apple and Windows signing certificates. This allowed them to produce a notarized macOS application and a signed Windows installer that bypassed standard security warnings. The malicious desktop app was distributed via the built-in updater to Windows x64 and Apple Silicon Mac users within ten minutes of publication. By 08:27 UTC, the compromised version had been downloaded 65 times. Maintainers withdrew the release after about 8.5 hours and issued a clean version, 0.56.3, which is identical to the previous safe version 0.56.1 but signed with a new certificate.

How it works

Both malicious releases contained a lightweight loader that downloaded and executed additional payloads from a remote server at api.frameworkmetrics[.]xyz. In bee-js, this loader ran as a postinstall script, executing automatically during installation even if the library was not imported by the user. In Swarm Desktop, the loader executed every time the application started. The downloaded code searched for specific files in the Swarm Desktop data directory: config.yaml and data-dir/keys/swarm.key. While the key file is an encrypted Ethereum keystore, the application stored the decryption password in plain text within config.yaml, allowing attackers to fully access the node’s wallet.

Beyond stealing credentials, the payload installed persistent backdoors tailored to each operating system. On Linux and macOS, it deployed a Go-based remote shell named evjawbreaker, hidden in a ~/.solidity folder and configured to run as a background service or LaunchAgent. On Windows, it installed a legitimate ScreenConnect remote-access client, using a known User Account Control bypass to gain administrator privileges if possible. The attackers controlled these backdoors via addresses stored in an Ethereum smart contract, allowing them to update command-and-control servers dynamically.

Key details

• Compromised versions: bee-js 13.3.0 and Swarm Desktop 0.56.2 were the only affected releases.
• Attack vector: Stolen CI credentials for the bee-worker account allowed unauthorized publishing and signing.
• Data theft: The malware stole swarm.key and the plain-text password from config.yaml, exposing node funds.
• Backdoor persistence: Malware installed services like solidity-langsupport-runner.service on Linux and ScreenConnect on Windows.
• Remediation status: Version 0.56.3 replaces the malicious desktop app, but Linux users must manually replace packages.
• Compromise assumption: Any machine that ran bee-js 13.3.0 or Swarm Desktop 0.56.2 is considered fully compromised.

Why it matters

This incident highlights the critical risk posed by compromised CI/CD pipelines in open-source projects. Because the attackers used the project’s own automation tools, the resulting packages carried valid provenance and digital signatures, effectively bypassing trust mechanisms that developers rely on. This demonstrates that supply chain security is not just about verifying code integrity but also about securing the infrastructure that builds and publishes that code. For teams using automated workflows, the absence of mandatory human approval steps for publishing can turn a credential leak into a full-scale supply chain attack.

For developers building on Swarm or using similar decentralized storage tools, the impact extends beyond simple software updates. The theft of node keys and passwords means that financial assets stored in these wallets are immediately at risk. Furthermore, the installation of persistent backdoors means that simply updating or reinstalling the software does not remove the threat. Engineers must treat affected machines as breached, requiring comprehensive rotation of secrets and potentially rebuilding systems from trusted images to ensure complete remediation.

What you can do

• Check your lockfiles and CI logs for any reference to @ethersphere/bee-js@13.3.0 and pin your dependencies to version 13.2.0.
• Inspect the bee-desktop.log file for the line "Bee Desktop version: 0.56.2 (production)" to determine if you ran the malicious app.
• If you ran Swarm Desktop 0.56.2, immediately move all node funds, chequebook balances, and stakes to a new key from a clean device.
• Remove persistent backdoors by deleting the ~/.solidity folder on Linux/macOS and the ScreenConnect Client service on Windows.
• Rotate all passwords, tokens, and API keys that were accessible to any user or CI job that installed the compromised bee-js package.
• Rebuild any machine that executed the malicious code from a trusted base image rather than attempting to clean it in place.