The @ethersphere/bee-js 13.3.0 compromise shows why legitimate publishing workflows and valid provenance cannot replace source integrity controls.
An automated build pipeline can execute perfectly and still publish malware.
That is the central lesson from the November 9, 2026 compromise of the npm package @ethersphere/bee-js.
GitHub flagged version 13.3.0 as malicious. StepSecurity traced the changes to an unexpected commit made under the project's bee-worker release identity.
The package was then published using the project's legitimate GitHub Actions workflow.
The resulting artifact carried valid SLSA provenance.
The problem was not that the build pipeline secretly substituted a different package.
The problem was that the pipeline built and published source code that had already been compromised.
Where the release process diverged
StepSecurity's investigation identifies an unsigned direct commit to the upcoming branch at 23:59:54 UTC on November 8.
The commit used the project's release naming convention.
However, the normal release pull request for version 13.3.0 was still open and had not been merged.
The previous 13.2.0 release had followed a signed, merged pull-request process.
The direct commit therefore represented a meaningful deviation from the expected release path.
At 00:06:01 UTC on November 9, the GitHub release was published.
The existing trusted-publishing workflow started immediately afterward.
At 00:09:50 UTC, npm received the compromised 13.3.0 package.
The publishing process completed as designed.
That is precisely why the incident matters.
The installation hook was the execution point
The malicious change modified package.json so that node scripts/generate-version.cjs ran during postinstall rather than prepare.
The release also included the script directory in the published npm package.
The modified script contacted an external server and retrieved JavaScript based on the host operating system.
It then executed the retrieved code with the permissions of the user running the installation.
There was no requirement for the application to import or invoke the affected library.
The installation itself was the execution opportunity.
This creates a particular risk for CI environments.
A build job may install dependencies and then run tests without ever executing the application's functionality.
Yet an installation hook may already have run.
If the job has access to cloud credentials, release tokens or other sensitive files, those resources may be exposed to a malicious installation process.
What the payload attempted
StepSecurity retrieved platform-specific JavaScript that looked for Swarm Desktop wallet files.
The targets included:
config.yaml
data-dir/keys/swarm.key
The keystore contains encrypted wallet information. The configuration file can contain the password needed to decrypt it.
The payload also attempted persistence using operating-system-specific mechanisms.
On Linux, it configured a user-level systemd service.
On macOS, it created a LaunchAgent.
On Windows, the retrieved script attempted to stage and run additional installer components.
The Linux executables were inspected statically, but not executed during the investigation.
Some macOS and Windows components could not be retrieved, leaving their complete capabilities unverified.
No confirmed number of compromised installations or stolen wallets has been established.
What valid provenance did—and did not—prove
SLSA provenance can provide valuable evidence that a package was produced from a particular source repository through a specified workflow.
That helps protect against certain forms of artifact substitution.
But provenance is not a declaration that the source code was reviewed, authorized or safe.
In this case, it accurately linked the published artifact to the project's actual workflow.
The malicious modifications were already present in the source.
The incident therefore crossed a different trust boundary: the transition from an authorized source change to a release.
A useful control is not merely verifying which workflow produced an artifact.
It is enforcing which commits that workflow is permitted to build and release.
That may involve protected branches, authenticated and reviewed changes, tightly scoped release identities and investigation of unexpected deviations from the normal release path.
The exact initial method used to misuse the bee-worker identity has not been confirmed.
How to check existing environments
The first step is to determine whether the affected release was resolved and installed.
For an existing npm project:
npm ls @ethersphere/bee-js --all
Look specifically for version 13.3.0.
Then check:
- Dependency lockfiles, including historical revisions.
- CI and deployment installation logs.
- Build artifacts and container images.
- Transitive dependencies that may have resolved to 13.3.0.
- Whether lifecycle scripts were enabled during installation.
A currently clean dependency tree does not prove that the malicious version was never installed.
If installation occurred, review network and endpoint telemetry for the indicators published by StepSecurity.
One relevant network indicator is api.frameworkmetrics[.]xyz, the attacker-controlled host used to deliver additional code and receive wallet data.
Linux investigators should also look for the reported solidity-langsupport-runner.service user service.
For macOS, the report identifies com.solidity.langsupport.runner.plist.
The complete indicator list should be taken from the technical report rather than inferred from a single filename.
If the remote payload executed, isolate the affected host, preserve evidence and rebuild from a trusted image after investigation.
Rotate credentials that were accessible to the affected user or CI job from a clean system.
If Swarm wallet files were available, treat the wallet as potentially exposed.
Removing the npm dependency does not necessarily remove persistence already created by the payload.
GitHub's advisory lists no patched version. StepSecurity found that the examined 13.2.0 release did not contain this specific malicious installation path, but that finding should not be interpreted as a guarantee about every other possible risk.
The engineering question
Software supply-chain security is often discussed as a problem of verifying what enters a deployment environment.
That is necessary.
But verification must be applied at the right point.
An artifact may be authentic.
The build may be reproducible.
The workflow may be legitimate.
And the source may still contain malicious code.
A reliable pipeline can faithfully deliver an unreliable input.
The incident should force engineering teams to ask a more specific question:
What proves that the source entering our trusted release workflow was authorized and appropriate to release?
That is a different question from whether the workflow completed successfully.
Sources
GitHub Security Advisory GHSA-hh7j-5m3j-23pf
https://github.com/advisories/GHSA-hh7j-5m3j-23pf
StepSecurity technical investigation
https://www.stepsecurity.io/blog/ethersphere-bee-js-13-3-0-compromise
Top comments (0)