"0.56.2 was published by an attacker using stolen CI credentials and has been withdrawn," one of the project's maintainers wrote — a blunt admission that the Ethersphere project's release automation itself was used to ship wallet‑stealing malware to users and developers.
Malicious releases: bee-js 13.3.0 and Swarm Desktop 0.56.2
Attackers published malicious versions of two Ethersphere projects: the JavaScript library bee-js (version 13.3.0) and the Swarm Desktop application (version 0.56.2). Both releases have been removed; maintainers replaced Swarm Desktop 0.56.2 with a clean 0.56.3 build signed with a newly issued Developer ID certificate, and npm again shows bee-js 13.2.0 as the latest version. At the time of writing no theft of funds had been reported.
Timing and download counts are limited but specific: bee-js 13.3.0 was the latest on npm for roughly 75 minutes (about 00:09–01:25 UTC) and was downloaded an estimated ten times, including scanners and mirrors. Swarm Desktop 0.56.2 appeared on GitHub at about 00:36 UTC and was withdrawn about 8.5 hours later; its download counter reached 65 by 08:27 UTC, a figure that included researchers.
How the malware operated and what it stole
Both releases carried the same lightweight loader (identified in technical analysis as SafeDep) that fetched additional code from api.frameworkmetrics[.]xyz and executed it with the user's permissions. In bee-js the loader ran as an npm postinstall script (which npm executes automatically unless install scripts are disabled); in Swarm Desktop the loader executed each time the app started.
The downloaded payload searched a Swarm Desktop data folder for two files — config.yaml and data-dir/keys/swarm.key — and sent them to the attackers' server. Swarm Desktop stores its password in plaintext in config.yaml, while swarm.key is an encrypted Ethereum keystore. With both files the attackers can recover the node wallet and take xDAI and xBZZ tokens, chequebook funds, and stake, the incident analysis says.
The payload also installed a backdoor. On Linux and macOS the malware dropped a Go remote shell named evjawbreaker into a hidden ~/.solidity/ folder and configured it as a user service (solidity-langsupport-runner.service or LaunchAgent com.solidity.langsupport.runner). The shell reads its control address from an Ethereum smart contract (0xf8a900Db50b3331be6B768bA460BB59f3E40C344), allowing the attackers to update the server address remotely — the contract was updated 29 minutes before the malicious bee-js code was added. On Windows the payload installed a ScreenConnect remote‑access client (identified as Service "ScreenConnect Client (5cbe79c9c25524df)") that ran as a system service and connected to the attackers' relay.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleHow the attackers abused CI and release automation
Both malicious releases originated from the project's bee-worker automation account. For bee-js, attackers published a GitHub release that triggered the project's npm publishing workflow; Socket's analysis shows that workflow required no approval and pushed the package to npm in 73 seconds. Because the project's real workflow built the package, the malicious npm package carried valid provenance — a record that links a package to its build workflow but not whether source code was reviewed.
For Swarm Desktop the attackers manually started a build workflow that had the project's Apple and Windows signing certificates and likewise needed no approval. The resulting macOS app was signed with the project's Developer ID and notarized by Apple, so macOS presented only the normal first‑launch prompt. After the incident, maintainers changed signing jobs to wait for explicit approval and to run only from the main branch.
The maintainers' note blames "stolen CI credentials and secrets" for the breach; Socket's analysis indicates two GitHub accounts were used (bee-worker and a long‑time maintainer account), but how credentials were exfiltrated was not explained.
Indicators of compromise and concrete remediation steps
The project's GitHub advisory is categorical: "Any computer that has this package installed or running should be considered fully compromised." SafeDep offers the same guidance for any machine where Swarm Desktop 0.56.2 was installed. Key indicators and actions published in the incident advisories include:
- Domain used by loader: api.frameworkmetrics[.]xyz (paths observed: /v1/analytics, /v1/electron, /v1/assets/, /v1/swarm/report; header X-Ethersphere: 1)
- Control servers and relays: 193[.]57[.]9[.]155:4912 (evjawbreaker control), 185[.]232[.]84[.]169:8041 (ScreenConnect relay)
- Ethereum contract used to publish control server address: 0xf8a900Db50b3331be6B768bA460BB59f3E40C344
- Local artifacts: ~/.solidity/, systemd unit solidity-langsupport-runner.service, LaunchAgent com.solidity.langsupport.runner, and Windows service ScreenConnect Client (5cbe79c9c25524df)
- Binary SHA‑256 hashes for known payloads and installers (several provided in the advisory)
Recommended remediation steps: search lockfiles, package caches, internal registries, and CI logs for @ethersphere/bee-js@13.3.0; pin to 13.2.0 and clear cached copies; if install scripts ran, treat the machine or CI runner as compromised even if logs show no errors; from a clean computer rotate every password, token, and key the installing user or CI runner could read. Swarm Desktop users should check if logs contain the line "Bee Desktop version: 0.56.2 (production)" (the app writes that at every launch just before the malicious code runs), install 0.56.3, and on Linux replace packages by hand. Where possible the advisories say to rebuild machines from trusted images rather than try to clean them in place.
What this means for Swarm Desktop users, open‑source maintainers, and security teams
Swarm Desktop users must assume a node that ever ran 0.56.2 had its node key and password exposed and, from a clean system, move node funds, chequebook balances, and stake to a new key. Open‑source maintainers face a sharpened trade‑off: automated CI that speeds releases can also be the vector of compromise if credentials and signing jobs are not tightly gated and require human approval. Security teams and DevOps must search CI logs and caches for @ethersphere/bee-js@13.3.0, clear mirrors and package caches, and treat affected runners as breached — rotating tokens and rebuilding hosts as necessary.
The attack shows how release automation can be weaponized: valid build provenance and properly signed and notarized binaries do not guarantee safety if signing jobs and CI secrets are controlled by an attacker. The maintainers have withdrawn the malicious artifacts and adjusted signing workflows, but the single remaining, open question in the record is how the credentials were taken — a detail that will determine whether similar projects can close the same gap.
Original report: thehackernews.com/2026/11/hackers-compromise-etherspheres-bee-js.html
