Compromised Swarm Releases Can Steal Wallet Keys and Credentials

Two Ethersphere software releases—@ethersphere/bee-js 13.3.0 and Swarm Desktop 0.56.2—contained malicious code capable of stealing wallet keys and credentials, according to SlowMist and Socket. The affected packages ran on Windows, macOS and Linux.

@ethersphere/bee-js is a JavaScript library, while Swarm Desktop is the desktop application. Both were distributed under Swarm's name through an official release process that SlowMist and Socket said had been hijacked after a GitHub account was compromised. The result was a compromised software-update path, not merely an unrelated malicious file found elsewhere.

The findings disclose no dollar loss, victim count, exploitation rate or number of wallets taken. Nor do they establish that every installation executed the payload. GitHub's security advisory nevertheless instructed users with either affected version installed to treat their devices as compromised, which sets a broader standard than demonstrated financial harm.

How did the malicious code reach users?

SlowMist and Socket traced the tampering to a compromised GitHub account and a hijacked official release process. That sequence allowed malicious code to enter packages distributed under Swarm's name, converting software updates into a potential route for secret theft. It also means a user could receive the compromised release through a channel that appeared legitimate.

The available findings do not specify how many releases were altered beyond the two, how long the account remained compromised or whether the two named versions were the only affected artifacts. The narrow answer is therefore specific: versions 13.3.0 and 0.56.2 are identified; the wider blast radius remains unquantified.

What can the malware do?

The malicious code was designed to steal wallet keys and credentials. Its operators also used an Ethereum smart contract to retrieve command-and-control, or C2, server addresses dynamically. The researchers said the same infrastructure had appeared previously in SleepyDuck and EtherDuck malware activity.

• Wallet and credential exposure: The code can steal wallet keys and credentials, creating a path to unauthorized wallet control and compromised accounts.
• Ethereum-based command retrieval: The malware reads C2 addresses from an Ethereum smart contract, allowing operators to change which servers infected devices contact.
• Recycled malware infrastructure: The same infrastructure was previously used in SleepyDuck and EtherDuck activity.

That Ethereum-based retrieval changes the operational problem. Blocking one server address would not necessarily stop access to the operator's current server set, because that set can change without another software release. The shared infrastructure does not, by itself, prove the same actors operated both campaigns, but it gives investigators a concrete link to examine.

The practical risk is secret theft backed by command infrastructure that operators can redirect.

Why did macOS trust markers not prevent execution?

The malicious macOS installer retained Apple's code signature and notarization despite containing malicious code, GitHub's advisory said. Code signing and notarization can help users assess provenance and integrity, but their presence did not make this installer safe. A system could therefore show recognizable trust markers while carrying harmful code.

The findings do not specify how the signature and notarization survived the compromise, leaving the precise trust-chain failure unstated. The important distinction is procedural: the installer retained Apple's signing and notarization markers, yet those signals did not exclude malicious content.

Apple's visible trust markers did not establish that the installer was benign.

What does the advisory require users to do?

GitHub's security advisory warned that devices with either affected version installed should be treated as compromised. That guidance applies even though the findings identify no documented theft from a named wallet, no confirmed victim total and no quantified loss.

The practical response is to regard affected installations as an exposure requiring replacement with a verified clean release and review of wallet keys and credentials that may have been exposed. The advisory's warning is not conditioned on proof of visible misuse.

Affected installations require a clean replacement and an exposure review.

When does the remediation window close?

The findings provide no fixed remediation deadline and do not announce a verified successor release. The defensible forward-looking test is therefore release-specific: users carrying @ethersphere/bee-js 13.3.0 or Swarm Desktop 0.56.2 remain within the exposure window until they install a version independently verified as clean.

Any wallet keys or credentials exposed during that period also require attention; otherwise, replacing the package alone would not remove the risk created by earlier theft. Until a successor package passes verification and users complete credential remediation, the exposure window for versions 13.3.0 and 0.56.2 remains open.