A compromise of Ethersphere’s release infrastructure shows why code signing and software provenance cannot guarantee that an application is safe.
Attackers compromised the software release process used by Ethersphere, distributing malicious versions of a JavaScript library and a desktop application despite the presence of legitimate publishing and code-signing protections.
The November 9 incident investigation by Socket identified two affected releases: @ethersphere/bee-js version 13.3.0 and Swarm Desktop version 0.56.2.
Both delivered malicious code designed to steal cryptocurrency wallet credentials and establish unauthorized access to affected computers.
The case exposes a weakness in modern software supply-chain security: a package can originate from a legitimate publishing workflow while still containing code introduced by an attacker.
Attackers Used Legitimate Release Infrastructure
According to SafeDep researcher Kunal Singh, the attacker modified a version-generation script within the bee-js project and configured it to run automatically during package installation.
The malicious code downloaded and executed additional JavaScript capable of accessing sensitive information on the affected computer.
Crucially, the attacker did not need to publish the package using an obviously unauthorized registry account.
Instead, the project’s existing GitHub Actions workflow generated and published the compromised release.
The package retained valid software provenance information, which records the repository and workflow responsible for producing an artifact.
That provenance was authentic. The problem was that the underlying release process had been abused.
Apple Notarization Did Not Prevent Distribution
Approximately 30 minutes after the malicious bee-js release, attackers published a compromised version of Swarm Desktop.
The Socket investigation found that all nine examined installation packages contained the malicious loader.
The macOS application was signed using the project’s legitimate Developer ID and notarized by Apple.
These measures verify aspects of software identity and distribution but do not independently establish that every instruction inside the application is harmless.
According to The Hacker News, the malicious npm package remained available for approximately 75 minutes, while the compromised desktop release was accessible for around eight and a half hours.
Malware Targeted Cryptocurrency Credentials
The malicious releases were designed to extract Swarm node configuration information and wallet credentials.
Researchers connected the infrastructure to the previously documented SleepyDuck/EtherDuck malware campaign, which used Ethereum-based mechanisms to locate command-and-control infrastructure.
The Windows payload could deploy a ScreenConnect remote-access client, while Linux and macOS systems received a separate backdoor.
Socket estimated approximately 10 downloads of the malicious npm version and identified up to 65 downloads of the compromised desktop release, including security researchers.
Those figures are not confirmed counts of infected computers.
No verified cryptocurrency losses had been publicly reported when the initial investigations were published.
Developers Must Review More Than Package Signatures
Ethersphere’s maintainers removed the malicious releases and published a clean Swarm Desktop 0.56.3 update.
The GitHub security advisory identifies the malicious bee-js version and warns that systems executing the package should be considered compromised.
Removing a malicious package does not automatically eliminate previously installed malware or invalidate stolen credentials.
For engineering teams, the incident demonstrates why software supply-chain controls must extend beyond artifact signatures.
Protected release branches, independent approvals, restricted automation credentials, dependency monitoring, and reproducible builds can help reduce exposure.
However, each control addresses a different part of the development process, and no single measure guarantees protection.
The larger lesson is that authentic software provenance does not necessarily mean trustworthy software. As development becomes increasingly automated, securing the authority to publish code may be as important as securing the code itself.
