Ethersphere's Own Release Pipeline Used to Ship Wallet-Stealing Malware via bee-js and Swarm Desktop

When the Supply Chain Is the Product

Ethersphere, the team behind the Swarm decentralized storage network, has confirmed that attackers abused its release automation to publish malicious builds of two of its tools. According to The Hacker News, the compromised versions are bee-js 13.3.0 and Swarm Desktop 0.56.2 — both distributed through the project's legitimate publishing channels.

The incident is a textbook example of why release infrastructure has become one of the highest-value targets in modern software supply chains. When an attacker controls the pipeline rather than the source repository, every downstream safeguard that depends on provenance — signed releases, trusted maintainers, familiar package names — works against the defender.

What the Malicious Builds Do

The payload is purpose-built for cryptocurrency theft. Once executed, the code attempts to extract the wallet key that Swarm Desktop maintains for its node, along with the stored password that unlocks it. For users running a Swarm node, that combination is effectively the keys to the vault.

Beyond credential theft, the implanted code is also designed to establish a backdoor on the host, giving the operators a persistent foothold rather than a one-shot exfiltration. That dual capability — steal now, stay resident later — is a familiar pattern in attacks against developer and infrastructure tooling, where the initial target is often a stepping stone to broader access.

Why This Attack Matters

Three factors make this incident more than a routine malicious package report:

Legitimate distribution. The malicious versions were published through Ethersphere's own release automation, not uploaded to a lookalike namespace. Users who verified the package name and publisher had little reason to be suspicious.

A crypto-native target set. Swarm Desktop users are, by definition, participants in a decentralized storage economy. Their node keys have direct monetary value, and the theft of a wallet key plus its password is not a recoverable event in most cases.

Developer tooling as an entry point. bee-js is a JavaScript library consumed by developers building on Swarm. Compromising a library means compromising every application and CI pipeline that pulls the affected version — a multiplier effect that far exceeds the population of desktop wallet users.

The Broader Pattern: Release Automation Under Fire

This is not an isolated case. Over the past several years, attackers have repeatedly demonstrated that CI/CD systems, package registries, and maintainer accounts are softer targets than well-audited source code. The common thread is the same: an automation identity with publish rights becomes the pivot point.

Defenders should treat release pipelines as tier-zero infrastructure. That means:

• Short-lived, scoped credentials for publishing, with no long-lived tokens sitting in CI secrets.
• Mandatory multi-factor authentication on registry and repository accounts, ideally phishing-resistant hardware keys.
• Signed artifacts with verifiable provenance (for example, SLSA-style attestations or Sigstore), so consumers can detect builds that did not originate from the expected workflow.
• Anomaly alerting on publish events — a new version appearing outside normal release cadence or from an unexpected runner is a signal worth investigating.

What Users and Developers Should Do

If you run Swarm Desktop 0.56.2 or depend on bee-js 13.3.0, treat the host as compromised. Rotate any node keys and passwords that were present on the machine, and re-provision rather than attempting to clean an environment where a backdoor was deliberately installed. Review outbound network connections and persistence mechanisms for signs of the implant.

Developers should pin dependencies to known-good versions and verify integrity hashes against a trusted source rather than relying solely on the registry. Organizations consuming bee-js in production should audit their lockfiles and CI caches for the affected release.

The Takeaway

Ethersphere's compromise is a reminder that the trust boundary of open-source software extends well past the code itself — into the accounts, tokens, and automation that turn source into shipping artifacts. Projects that have not yet hardened their release pipelines should assume they will be tested.

For the full report and updates from the project, see the original coverage at The Hacker News.