Short answer: On 9 November 2026 The Hacker News, citing Socket and SafeDep, reported that attackers had published a malicious EtherSphere bee-js package, version 13.3.0, to the npm registry, where it sat for about 75 minutes, and that a related Swarm Desktop release, 0.56.2, had also been withdrawn. The malicious package, the report said, ran a postinstall loader; version 13.2.0 was again the latest bee-js on npm, and Swarm Desktop 0.56.3 was described as clean. The maintainer, as quoted in that coverage, said the package was published with stolen CI credentials. Because a real workflow built it, the package could still carry valid npm provenance. Provenance is not the same thing as a reviewed release. The public GitHub advisory GHSA-hh7j-5m3j-23pf states: “Any computer that has this package installed or running should be considered fully compromised.” It lists no patched versions of the compromised release. If you maintain or consume npm packages, keep dated lockfiles, SBOMs and release artifacts, and rotate credentials from a clean machine if you may have installed the bad release. A TimeBind cannot tell you a package is safe. It can date the exact files you kept.
Last checked 12 November 2026. General information for developers, not incident-response, legal or security-certification advice, and not a finding about any maintainer or any downstream project. The account of the bee-js incident follows The Hacker News report of 9 November 2026 and the public GitHub advisory GHSA-hh7j-5m3j-23pf. A dated lockfile does not detect malware, and TimeBinder does not scan packages.
Table of Contents
What was reported
The Hacker News article of 9 November 2026, drawing on research from Socket and SafeDep, describes a short-lived compromise of EtherSphere’s bee-js package on the public npm registry. According to that report, version 13.3.0 was published with a postinstall loader, remained available for about 75 minutes, and was then withdrawn. A related desktop product, Swarm Desktop 0.56.2, was also withdrawn; 0.56.3 was described as a clean replacement, and bee-js 13.2.0 was again the latest version of that package on npm.
The same coverage says the malicious release was published with stolen CI credentials. That detail matters for how developers read supply-chain signals. npm provenance can show that a package was built by a named workflow in a real repository. If the attacker used the real workflow, the provenance attestation can still be valid. A valid attestation is not a code review, and it is not a finding that the package is benign.
The public GitHub advisory GHSA-hh7j-5m3j-23pf is the official wording to use for impact. It states that any computer that has this package installed or running should be considered fully compromised, and it lists no patched versions of that compromised release. Follow the advisory, and the project’s own notices, rather than a blog post’s reconstruction of a cleanup. This page is not an incident-response playbook and does not invent steps the advisory does not contain.
The story moved quickly on X the same day and the next. When public metrics were read on 12 November 2026, a 9 November post by @solidintel_x had 14,782 impressions; on 10 November, @SlowMist_Team had 6,158, @SolanaFloor had 5,284, and @nehalzzzz1 had 4,760. Google autocomplete on 12 November suggested “npm package hijacked.” YouTube coverage inside the window was small: a 10 November TechIn60 clip had 18 views, and a 10 November DevOps Roundup had 272 views, when checked on 12 November.
What this does and does not mean
A 75-minute window is short, and it is long enough for automated installs, caches and CI jobs to pull a package. Whether any given project was affected is a question of lockfiles, registries, mirrors and install logs, not of a headline. The advisory’s “fully compromised” language is about machines that installed or ran the bad package. It is not a claim about every EtherSphere user, and it is not a claim about unrelated npm incidents.
Two other limits are easy to miss. First, withdrawing 13.3.0 and publishing a clean desktop build does not rewind an install that already happened. Second, a dated record of a good lockfile is useful only if you still have that file. If the only copy you have was written after a rebuild, it may already include the bad version, or it may have moved past it. Keep install logs and the lockfile from the time of the install, not only the file that is in the repo today.
Practical checklist for maintainers and consumers
- Start from the official advisory, not from a thread. Read GHSA-hh7j-5m3j-23pf and the project’s own notices. If a machine may have installed bee-js 13.3.0 or Swarm Desktop 0.56.2, treat that machine as the advisory says, and rotate credentials from a system you believe is clean. This page does not add extra cleanup steps.
- Check lockfiles, install logs and CI caches for the affected versions. Look for bee-js 13.3.0 and Swarm Desktop 0.56.2, including in artifacts and mirror caches, not only in the current branch.
- Do not treat npm provenance as a review. In this incident, coverage said a real CI workflow published the package, so a provenance attestation could still be valid. Provenance answers “which workflow built this?” It does not answer “was the workflow still only in the maintainer’s hands?”
- Keep dated copies of the lockfile, the SBOM and the release artifact you actually shipped or deployed. If you later need to show what was in a build, the file from that day is the one that matters. See how to show that source code existed before a date and what to keep when a project’s licence or release line is in question.
- Keep a record of the registry and the install command. A package-lock, pnpm-lock or yarn.lock, plus the CI log that shows the resolved URL and integrity hash, is stronger than a recollection of “we were on 13.2.0.”
- If you publish packages, review how CI secrets are stored and how a release is approved. Stolen CI credentials are a recurring pattern. A TimeBind of a release tarball does not protect a token that is already in a workflow.
- If an agent or a script has write access to the same machine, treat that as part of the same review. For a different failure mode — an agent that deleted files — see what to do before you give an agent access. For a broader vendor-tool risk, see GitHub Copilot and Cursor training opt-outs.
- Date the pack you would hand to a security reviewer. A TimeBind of a lockfile, an SBOM, a release artifact or a CI log lets you show that those exact files existed no later than a recorded time and still match. It does not tell you the package was clean.
What a TimeBind does and does not show
A TimeBind is a dated, checkable record that an exact file existed no later than a recorded time and still matches. The SHA-256 fingerprint is made in your browser and the file is never uploaded. The record is anchored to Bitcoin (a Merkle root in an OP_RETURN). Your first Pooled TimeBind is free; after that, TimeBinds start from US$5, and an ASAP TimeBind is US$15. See how it works.
Here it is useful for a lockfile, an SBOM, a release tarball or checksum list, and a saved CI log. It shows that those exact files existed no later than the recorded time and still match.
A TimeBind does not scan a package for malware, does not verify npm provenance, does not rotate a token, and does not prove that a build was safe to install. If a machine may already be compromised, date new artifacts only after you are working from a clean environment. A record made on an untrusted host is a record of a file on that host, nothing more.
Limits
We have not audited bee-js, Swarm Desktop or any downstream project, and we are not restating a full incident-response plan. Version numbers, withdrawal times and the 75-minute window are taken from The Hacker News report as read on 12 November 2026; if the project or GitHub advisory is later updated, follow that update. npm, GitHub and CI vendors change product behaviour. This page is not a general guide to every npm hijack, and it does not replace GHSA-hh7j-5m3j-23pf.
Tools that can help
Keep lockfiles and SBOMs in a repository you control, then use the bulk SHA-256 manifest if you also store release artifacts as files. For a developer overview, see the developers hub.
A neighbouring, narrower job is moving an npm package to trusted publishing. The free npm trusted publishing checklist looks at the settings that must match, old tokens and the exact copies to keep. It is not a security audit.
A neighbouring job for Python packages is moving to trusted publishing on PyPI. The free PyPI trusted publishing checklist looks at what you trust, old API tokens and the exact copies to keep. It is not a security audit.
If a compromised npm package version may have been installed in your projects, see also the free npm package compromise response checklist. It puts the steps in order, search, treat the machine as exposed, rotate, rebuild, and cannot show whether a machine is clean.
Frequently Asked Questions
-
What happened to EtherSphere’s bee-js package?
According to The Hacker News on 9 November 2026, citing Socket and SafeDep, a malicious bee-js 13.3.0 was published to npm, stayed up for about 75 minutes, and was withdrawn. Swarm Desktop 0.56.2 was also withdrawn; 0.56.3 was described as clean, and bee-js 13.2.0 was again the latest on npm. Coverage said the publication used stolen CI credentials.
-
What does the GitHub advisory say?
GHSA-hh7j-5m3j-23pf states that any computer that has this package installed or running should be considered fully compromised, and it lists no patched versions of the compromised release. Follow that advisory and the project’s own notices.
-
Does valid npm provenance mean a package is safe?
No. In this incident, coverage said a real CI workflow published the package, so provenance could still be valid. Provenance can show which workflow built a package. It does not mean the workflow or its credentials were still only under the maintainer’s control.
-
What should developers keep?
Dated lockfiles, SBOMs, release artifacts, CI logs that show resolved versions and integrity hashes, and the official advisory as you first read it. If a machine may have installed the bad release, treat it as the advisory says and rotate credentials from a clean system.
-
Can a TimeBind detect a malicious package?
No. A TimeBind does not scan for malware and does not verify a registry attestation. It is a dated, checkable record that an exact file existed no later than a recorded time and still matches.
Sources checked
- The Hacker News, “Hackers Compromise EtherSphere’s bee-js npm Package,” 9 November 2026, https://thehackernews.com/2026/11/hackers-compromise-etherspheres-bee-js.html (read 12 November 2026)
- GitHub Advisory GHSA-hh7j-5m3j-23pf (read 12 November 2026)
- X, public metrics read 12 November 2026: @solidintel_x, 9 November 2026 (14,782 impressions); @SlowMist_Team, 10 November (6,158); @SolanaFloor (5,284); @nehalzzzz1 (4,760)
- YouTube, 10 November 2026: TechIn60 (18 views) and DevOps Roundup (272 views), checked 12 November 2026
- Google autocomplete, 12 November 2026 (US): “npm package hijacked”
Date the lockfile and release artifacts you keep yourself
Your first Pooled TimeBind is free, with no credit card required. After that, TimeBinds start from US$5, and an ASAP TimeBind is US$15. Click here to start, or see plans and pricing.
Related: GitHub Actions CI secret stealer: what developers should keep.
