Ethersphere supply-chain breach hijacks wallet keys through npm and desktop releases

Malicious releases turn trusted software updates into wallet-key stealers

Attackers hijacked Ethersphere’s npm and GitHub packages, abusing compromised maintainer accounts and project release workflows to distribute malicious `@ethersphere/bee-js` 13.3.0 and Swarm Desktop 0.56.2 releases. The packages were designed to steal cryptocurrency wallet keys and deploy cross-platform backdoors. The practical significance is not limited to Ethereum developers.

Anyone who installed either compromised release may have exposed wallet credentials to attackers, while developers and organizations that trusted the project’s release infrastructure may also need to examine how the malicious versions entered their systems. This incident illustrates how hijacked npm packages can turn Ethereum-related transactions into malware infrastructure, as discussed in our analysis of hijacked npm packages turning Ethereum transactions into malware infrastructure.

Wallet theft and backdoors broaden the compromise beyond one package

The malicious bee-js release and trojanized Swarm Desktop version were not limited to stealing a single value or file. Reports identify wallet-key theft alongside the installation of backdoors, including on Windows and macOS. reported that the compromised releases reused SleepyDuck’s Ethereum-addressed command-and-control infrastructure. That reuse links the attack to an established malware technique and explains why the malicious software could behave as a coordinated cross-platform threat rather than an isolated modification to one library.

For security teams, the relevant assets extend beyond wallet files. Credentials held by developers, secrets exposed to build or release systems, and access tokens available to compromised machines may all require review.

Continuous-integration credentials become the critical control point

The attackers compromised two Ethersphere GitHub accounts and used the project’s CI to publish the malicious `@ethersphere/bee-js` 13.3.0 package and the trojanized Swarm Desktop 0.56.2 release. This means package publication was the observed delivery mechanism, not necessarily the initial point of intrusion. That distinction matters for remediation.

Replacing the affected versions addresses direct exposure, but it does not establish that the publishing environment is safe. Teams and maintainers should review account access, CI configuration, release permissions, signing attestations, and the logs surrounding the affected publications. The attack also shows why cryptographic integrity checks need to complement familiar package-management controls.

Hash generation can help compare downloaded artifacts with expected values, but a clean hash is only useful if the expected value comes from a trusted, independently protected source. The available Sha512 Hash Generator and SHA256 Hash Generator support that verification workflow; they do not determine whether a package itself is malicious.

Clean replacements provide an immediate rollback target

BrandDefense directs users of the compromised releases to move to clean `@ethersphere/bee-js` 13.2.0 and Swarm Desktop 0.56.3 versions. Those are the specific remediation releases identified in the evidence. Teams should replace the malicious versions rather than merely removing them, then determine whether the affected software ran with access to wallet keys or other sensitive material.

Removal alone does not undo possible credential theft, and replacement does not establish that the release infrastructure has been secured. The incident also highlights why asset inventory and version checks remain practical controls. A Text To HEX or related artifact-conversion utility can assist with encoding data for inspection, while an AES Encryption Online tool can help practitioners handle sensitive data outside plaintext workflows.

Neither tool substitutes for compromised-password rotation, token revocation, or release-pipeline review.

Wallet exposure should trigger a broader response

The confirmed malicious versions were `@ethersphere/bee-js` 13.3.0 and Swarm Desktop 0.56.2. Users of those releases should move to clean 13.2.0 and 0.56.3 versions and assess whether their systems exposed cryptocurrency wallet keys. The immediate response should include identifying installations of the affected versions, moving to the clean releases, revoking exposed wallet credentials, reviewing tokens and secrets accessible to the affected machines, and examining whether attacker-controlled code established persistence.

Incident responders should also preserve relevant logs before they rotate credentials or rebuild environments. For organizations that consume the package through automated builds, the review must extend to build outputs and downstream artifacts produced while the compromised versions were present. Merely scanning direct developer laptops would leave a material gap.