Global News | November 12, 2026

A malicious release of the Ethersphere JavaScript package and a compromised version of Swarm Desktop exposed users to wallet-key theft and backdoors, according to a GitHub security advisory and research from software supply-chain security firm Socket.

The Ethersphere supply chain attack involved @ethersphere/bee-js version 13.3.0 and Swarm Desktop version 0.56.2. Socket says attackers used the project’s release automation to distribute both artifacts through official channels on November 9, 2026.

The malicious package and desktop release were removed, and reporting says a replacement desktop version was issued. Removal alone does not undo code that may already have run. GitHub’s advisory says computers that installed or ran the affected bee-js package should be considered fully compromised and that secrets and keys should be rotated from a different computer.

Public reporting reviewed for this article did not establish a total number of infected machines or confirm cryptocurrency losses. Download counts and estimates include researchers and automated systems, so they cannot be treated as a verified victim count.

A Trusted Release Path Turned Against Users

Ethersphere develops software for Swarm, a decentralized storage network. The bee-js package is a JavaScript client library used by Swarm tools and applications. Swarm Desktop is an application that installs and runs a Bee node, including a wallet associated with the node.

On November 9, Socket reported that a threat actor used the project’s GitHub automation to publish the malicious bee-js release to npm and a trojanized desktop release on GitHub. The research describes both artifacts carrying a loader designed to fetch and execute additional JavaScript.

This is a software supply-chain incident: users could encounter malicious code through a distribution route they would ordinarily treat as legitimate. The public research does not establish that everyone using Swarm or every version of its software was affected.

The GitHub advisory identifies exactly 13.3.0 as the malicious bee-js package version. A separate issue in the Swarm Desktop repository identified 0.56.2 as malicious. The two version numbers refer to different products and should not be treated as interchangeable.

The Npm Package and Its Installation Hook

Socket says the malicious bee-js package changed a script into a loader and used an npm postinstall hook to run it during installation. A postinstall script can execute when a package is installed, depending on the installation environment and whether scripts are enabled.

A project did not necessarily need to import or explicitly use the malicious library for an enabled installation hook to run. Socket says some Swarm-related applications accepted version ranges that could include the affected package, making dependency and lockfile review important.

The researchers say the package was published through a legitimate trusted-publishing workflow and carried valid provenance. A provenance attestation can identify a build and publishing path; it does not guarantee the source code was authorized or harmless.

GitHub’s malware advisory warns that removing the package does not guarantee removal of all malicious software that may have resulted from installation. Its advice is to treat a computer that installed or ran the package as fully compromised and rotate accessible secrets and keys from a separate computer.

The advisory describes the affected version as 13.3.0 and lists no patched version for that malware entry. That does not mean every other release is malicious; it means users should follow current maintainer and security guidance rather than interpreting the advisory as a conventional patched-version table.

A Compromised Desktop Release

Socket also examined Swarm Desktop 0.56.2. The firm says all nine installer packages it unpacked for Linux, macOS and Windows contained the loader. The macOS build was signed with the project’s Developer ID and notarized by Apple, according to Socket.

A valid signature or notarization can help establish how an artifact was distributed or processed, but it does not by itself prove the code was benign. In this incident, the researchers say the malicious build passed through the project’s own signing and release process.

Socket reported that the app’s auto-updater could offer the release to Apple Silicon and Windows x64 users. The Hacker News reported that Linux installations did not update automatically and that Intel Macs were not offered the compromised release by that updater. Availability through an updater is not the same as proof that an individual machine installed or executed it.

The Hacker News reported that maintainers withdrew 0.56.2 and issued version 0.56.3 as a clean replacement. Users should confirm the current official release and platform-specific instructions before installing anything. Replacing the desktop app alone cannot establish that any previously installed backdoor has been removed or that an exposed key is safe.

Wallet Data and Backdoor Risk

SafeDep’s analysis describes later-stage code targeting a Swarm node’s configuration and encrypted wallet-key file. The researchers say the configuration could contain the password needed to unlock the keystore. Together, those files could give an attacker access to the node’s wallet and related assets.

The Ethersphere supply chain attack therefore created a potential financial risk in addition to the risk of a compromised computer. The sources reviewed do not establish that every installation reached the later stage, that every targeted file was present, or that funds were stolen from every user.

Socket describes loaders that retrieve and execute additional code with the privileges available to the process. SafeDep describes platform-specific backdoor behavior. These are findings from the researchers’ analysis, not independent reverse engineering by NewsFlayer.

A compromised device can expose more than a single application. Credentials, development tokens and other secrets accessible to the affected user or automation environment may require investigation and rotation. Rotation should be performed from a separate trusted device, as the GitHub advisory recommends.

Distribution Window and Uncertain Impact

Socket says npm served bee-js 13.3.0 as the latest version for approximately 75 minutes before removing it. The firm says the desktop release remained available for around eight and a half hours before it was withdrawn.

The research estimated roughly ten fetches of the malicious package based on traffic, including scanners and mirrors. Socket also reported that the desktop release’s counters reached 65 downloads at one point, including researchers. These measures have different limitations and are not equivalent to confirmed infected people or devices.

The Ethersphere supply chain attack may also have left copies in caches or third-party mirrors after removal from the primary registry. Socket documented a remaining copy on a mirror during its investigation. Organizations should check internal registries and caches in addition to the public package source.

The Hacker News said no theft of funds had been reported at the time of its review. That is a time-limited reporting observation, not proof that no loss occurred or that the final investigation is complete. No public total of compromised hosts or stolen assets was established in the sources used here.

What Is Known About the Release Pipeline

Socket’s analysis points to compromised GitHub accounts associated with a maintainer and the project’s release automation. The researchers distinguish server-recorded push activity from commit author fields, which can be set by a client and do not independently identify an attacker.

The Hacker News reported that a maintainer’s incident note attributed the desktop release to stolen continuous-integration credentials. The precise means by which the attacker obtained access was not established in the reporting reviewed.

Socket says the malicious npm release was published through the project’s existing workflow. Its account describes a workflow that did not require an approval step for that release path. This finding illustrates a control gap in a specific pipeline; it should not be generalized into a claim that all npm trusted publishing is insecure.

Researchers also identified similarities between later-stage infrastructure and a previously documented campaign. Infrastructure overlap is an analytical observation, not conclusive public identification of an individual attacker. The available sources do not establish a named perpetrator or government affiliation.

Practical Response for Developers

Check for the affected package

Search project lockfiles, build records, package caches, internal registries and continuous-integration logs for @ethersphere/bee-js 13.3.0. Check indirect dependencies as well as applications that explicitly declare the package.

If the affected version was installed or run, follow GitHub’s recommendation to treat the computer as fully compromised. Investigate whether installation scripts were enabled and what credentials the installation process could access. A clean-looking application startup or the absence of an obvious error is not proof that the machine was unaffected.

Remove affected artifacts from controlled caches and mirrors, but do not treat package removal as complete remediation. Use current guidance from project maintainers and qualified incident responders when deciding how to rebuild or restore a system.

Rotate secrets from a clean device

Identify API tokens, passwords, signing keys and other secrets accessible to the affected user or build job. Rotate or revoke them from a different trusted computer. Review the permissions and downstream services connected to each credential.

Preserve relevant logs and evidence before rebuilding where feasible, while balancing that work against the need to contain active risk. If an automated runner was affected, examine its access to repository secrets, package-publishing permissions and cloud credentials.

A lockfile update or clean reinstall may stop the malicious package being selected again. It does not revoke a stolen token or prove that a persistent implant has been removed.

Practical Response for Swarm Desktop Users

Check whether Swarm Desktop 0.56.2 was installed or executed. Use the project’s current release instructions and trusted distribution channels to obtain an appropriate replacement. The Hacker News reported that 0.56.3 replaced the withdrawn release; verify current guidance for your operating system before acting.

If the compromised desktop version ran, treat the machine and relevant wallet credentials as potentially exposed. Seek qualified assistance to investigate or rebuild the device, and use a separate clean computer for sensitive recovery actions. The project’s advisory and security researchers provide more specific technical guidance.

Users may need to replace wallet keys and secure assets associated with the node. The correct steps depend on the wallet, funding arrangements and operational setup. Avoid following unsolicited instructions to disclose a recovery phrase, send assets to a supposed support address or connect a wallet to an unfamiliar website.

An app update is important, but the Ethersphere supply chain attack demonstrates why recovery can require a broader review. A backdoor or copied secret may remain useful to an attacker after the original malicious application has been removed.

Lessons for Software Maintainers

Release pipelines can be attractive targets because they connect repository permissions, build systems, signing credentials and package distribution. Maintainers should review who can create release tags, trigger builds, approve publishing jobs and access signing material.

Protected branches are useful, but they do not automatically protect every release path. Organizations should check whether a publishing workflow can release code from an unreviewed tag or commit, and require appropriate approval for sensitive operations.

Monitoring and incident plans should cover registry removal, third-party mirrors, caches, credential rotation and communication to users. A signed artifact or valid provenance can be useful evidence during an investigation while still being insufficient as a standalone safety guarantee.

Conclusion

The affected bee-js and Swarm Desktop releases show how malicious code can reach users through a project’s own distribution workflow. GitHub identifies bee-js 13.3.0 as malware, while Socket and other researchers describe a separate compromised Swarm Desktop 0.56.2 release.

Users should verify exposure, follow current maintainer guidance and treat affected systems and accessible secrets with appropriate caution. The number of compromised machines and any final financial losses remain unconfirmed in the sources reviewed.

Source note: This report draws on the GitHub Advisory Database, Socket, SafeDep, the Swarm Desktop issue tracker and The Hacker News. NewsFlayer has not independently analyzed the malicious code or verified individual losses.

NewsFlayer — Bringing You the Latest Cybersecurity News from Around the World.