0x7cb6356b7cb6…7cb63568
Poisoned Ethersphere Releases Target Swarm Node Wallets
Ethersphere’s official pipeline shipped malware in bee-js 13.3.0 and Swarm Desktop 0.56.2. Node operators must remove persistent backdoors and rotate exposed wallet keys.

Outputs
On November 9, 2026, attackers compromised Ethersphere's automated release process.
bee-js 13.3.0 shipped around 00:09 UTC; Swarm Desktop 0.56.2 followed about 27 minutes later.
The packages used automatic postinstall hooks to download malware and exfiltrate Swarm node key files.
The malware targeted xDAI, xBZZ, chequebook funds and node stake; the report gave no confirmed loss figure.
GitHub advisory GHSA-hh7j-5m3j-23pf says affected machines should be treated as fully compromised.
By Marcus Bennett
Two compromised Ethersphere releases reached users through the project’s official pipeline on November 9, 2026. Malicious builds of the @ethersphere/bee-js npm package, version 13.3.0, and Swarm Desktop, version 0.56.2, targeted Swarm node wallet keys, according to GitHub advisory GHSA-hh7j-5m3j-23pf.
The npm package appeared around 00:09 UTC. The desktop app followed at roughly 00:36 UTC, about 27 minutes later. Ethersphere’s automated release process had been compromised before either build reached users.
Investigators have not established which part of the pipeline failed. The reported attack used either the bee-worker bot or stolen Continuous Integration credentials. Both routes gave attackers access to trusted distribution channels, allowing them to publish poisoned versions without bypassing normal release controls.
Each malicious package included a postinstall hook. The script ran automatically during installation, without another click, contacted a server controlled by the attackers and downloaded additional payloads. Installing the release therefore executed attacker-controlled code on the user’s machine.
The malware searched for two sensitive Swarm node wallet files: config.yaml and data-dir/keys/swarm.key. The latter contained an encrypted Ethereum keystore, while the password needed to unlock it sat in plaintext nearby. Attackers exfiltrated the stolen files and installed persistent backdoors across multiple platforms.
According to the research findings cited in the incident report, the payloads aimed to drain xDAI and xBZZ tokens, along with chequebook funds and stake tied to Swarm nodes. That objective covered both liquid balances and capital committed to node infrastructure. The report did not provide a confirmed loss figure or identify the number of wallets drained.
The GitHub advisory gave affected machines no benefit of the doubt: “Any machine that installed the compromised package should be treated as ‘fully compromised.’” Ethereum Swarm also directed users to its Discord channel, where the project urged them to secure their systems and replace the affected desktop release.
What does this change for Swarm node operators?
Patching the software does not resolve the exposure. The malware copied the keystore and its nearby plaintext password before the attacker’s backdoor was removed. Funds protected by those keys remain at risk even after users install a clean version.
Anyone who installed bee-js 13.3.0 or Swarm Desktop 0.56.2 should take three steps:
- Treat the machine as compromised and remove the installed persistence mechanisms.
- Replace the exposed Swarm wallet keys rather than relying on the old keystore.
- Install a clean desktop release and verify that the malicious package no longer runs during installation.
Developers who depend on bee-js face a broader cleanup. A compromised dependency can turn a build server or teammate’s laptop into another entry point. The source recommends immediate dependency audits and lockfile reviews, alongside the node-key replacement work.
The attack also used infrastructure linked to a previous malware operation known as the SleepyDuck campaign. That connection gave researchers a known fingerprint, but the use of legitimate release infrastructure remains the central operational problem.
Supply-chain attacks distribute risk through the channel users already trust. Developers pulling bee-js from npm and desktop users updating through official channels followed ordinary security practice. They still received code capable of running before they could inspect it.
The postinstall mechanism magnifies that risk. Package managers permit such scripts for legitimate work, including compiling native code. The same convenience allows malicious code to execute during routine installation, before a user has time to review the package or question the update.
For Ethersphere, remediation extends beyond cleaning affected computers. The project must explain whether the bee-worker bot or stolen CI credentials enabled the breach. It also needs to change the release process so one compromised account or pipeline cannot publish another malicious build.
The cited advisory and Discord response set no remediation deadline. Until Ethersphere identifies the compromised path and hardens its pipeline, the response window for checking installations, removing backdoors and rotating keys remains open.
via Crypto Briefing (Source)
More from Marcus Bennett
Show full bio
Senior reporter covering money, funding and market shifts around crypto and web3 industry at Mempool Brief.
734 articles