Ethersphere bee-js 13.3.0 and Swarm Desktop 0.56.2 Shipped Malware (November 2026): Affected Versions and What Users Should Do

• bee-js: check lockfiles, node_modules, package caches, internal package mirrors and CI logs for @ethersphere/bee-js 13.3.0. The advisory lists 13.3.0 as the only affected version
• Swarm Desktop: check whether the app version was 0.56.2 and whether you launched it. According to the security firm's analysis, it was also delivered by auto-update to Windows x64 and Apple Silicon
• bee-js 13.2.0 and earlier, and Swarm Desktop 0.56.1, are not affected (the security firm's analysis)
• If you cannot tell, treat it as affected (our addition)

The advisory says to treat any computer with the package installed or running as fully compromised, and to remove the package. It warns that removal may not clear all the malicious software the install caused.

• Disconnect the machine from the network and, if possible, rebuild it. Recreate disposable CI runners
• Do the rest of the work from a different, uncompromised computer

According to the security firm's analysis, the Bee node's configuration file (which includes a plaintext password) and its encrypted wallet key were targeted. Its guidance:

• Assume the password and wallet key were stolen
• Create a new key on a clean machine and move funds, chequebook balances and stake to it
• Look for persistence left behind by the malware (user-level auto-start entries, remote-control software). Reinstalling the app may not remove it

Whether any keys were actually stolen or any loss occurred has not been published. Until you can confirm otherwise, acting as if they were stolen is the safe course (our view).

The advisory says to rotate all secrets and keys stored on the machine immediately, from a different computer. It does not list them. The following is our addition, in line with the security firm's description of what the installing user or CI job could reach.

• npm and GitHub tokens, cloud keys, SSH keys
• CI secrets, and the short-lived cloud credentials issued to CI (via OIDC)
• Credentials saved in the machine's browser or password store

Setting up the new credential before disabling the old one avoids downtime (our addition). The basics of where to keep keys are in What makes .env files and API keys risky.

• bee-js: pin to 13.2.0 (the security firm's guidance). There is no patched version (advisory)
• Swarm Desktop: update to 0.56.3. Linux is not auto-updated and needs a manual update (the security firm's analysis). The update removes the compromised version, but it does not undo what has already run

The malicious version was on npm for about 75 minutes. Pinning versions in a lockfile, installing exactly as locked in CI (for example with npm ci), and using only versions published more than a set number of days ago (pnpm's minimumReleaseAge, uv's exclude-newer and similar) makes it harder to pick up a version that is withdrawn within minutes. The approach is covered in Defending against npm supply-chain worms.

According to the security firm's analysis, the bee-js malware ran through an install-time script. Turning off install scripts for dependencies by default (--ignore-scripts, an allow-list in pnpm) and allowing only what is needed reduces the effect of this kind of compromise (our addition).

According to the security firm's analysis, the npm package carried valid provenance attestations, because the malicious code ran inside the real publish workflow. Provenance shows where a package was built; it does not guarantee that the contents are safe (our addition).

According to the security firm's analysis, Swarm Desktop kept the password in plaintext in a configuration file. Keeping keys that hold funds apart from everyday development environments makes it less likely that a compromise of one leads straight to the funds (our addition).

For maintainers, the security firm's analysis recommends checking inside the publish workflow that the commit is on a protected branch, adding required reviewers and tag restrictions to publishing environments, not passing signing secrets to workflows that run on arbitrary branches, and narrowing and rotating release-bot tokens. If you publish packages, check the same points.