bee-js and Swarm: a genuine release can carry unapproved code
A release built by a project’s automation still requires review of the code it was authorized to publish. The bee-js and Swarm Desktop case also separates replacing software from recovering the environment that executed it.
Читати португальськоюBy Pentesty
The versions and the scope of confirmation
The GitHub advisory identifies malware in @ethersphere/bee-js 13.3.0, without listing a first patched package version. SafeDep describes an installation hook and a loader in Swarm Desktop 0.56.2, with code targeting the node key and its stored password. That capability does not quantify victims or losses.
The note merged in PR 582 attributes the compromised Desktop release to stolen CI credentials. Version 0.56.3 was published on November 9, 2026 as a replacement based on 0.56.1. This describes the project’s response; accepting an environment that executed suspicious code requires additional evidence.
Provenance does not replace content approval
Socket verified genuine provenance for the malicious package and signing and notarization for the macOS application. Interpret those signals according to what they establish. They do not replace the decision to authorize a commit’s content or the behavior of the artifact that reached the user.
In your own pipeline, connect the identity requesting a release, the event starting the workflow, the approved commit and the resulting artifact. Check whether alternative paths receive the same assessment. The approval rule needs to reach actual publication, including tagged releases and manual runs that can access secrets or signing capabilities.
Distinguish installation, distribution and execution
Keep separate inventories for the package and the application. Record resolved version, artifact origin, installation time and script-execution policy; for the application, seek evidence of installation and launch. A download record alone does not establish which actions occurred or which resources were reachable at that time.
Use available records to define groups with comparable evidence. A machine that merely stored an installer and a pipeline that executed code during installation require different questions. Where information is missing, retain the identified uncertainty. Do not turn download estimates into a count of compromised computers. Preserve the distinction between a resolved dependency and a file that was actually present on disk. Where a shared build cache or internal mirror is involved, identify its owner and which approved process can replace the stored artifact. Keep the affected time window alongside each source of evidence.
Assess more than the installed version
The package advisory warns that removal may leave resulting malicious software and advises changing secrets from a different computer. The team needs to distinguish replacing the artifact, recovering the device and recovering the identities that it could use.
Map the user or CI job that performed the installation, the secrets it could read and the resources it could reach. Separate long-lived credentials from issued sessions and include each service owner. Decisions about node and wallet keys require the responsible owner; do not automatically reproduce financial procedures within a technical exercise.
Define the evidence needed before resuming work
Within an authorized scope, use your own project and harmless markers to compare publication paths. Record which events require review, who can approve them and how the approved artifact is identified. Preserve traceability between the decision, commit and distributed output, without downloading or executing samples from the incident.
For recovery, agree on expected outcomes with administrators: approved software installed, environment state assessed and unauthorized access refused. Preserve the records supporting each conclusion. Document the scope and review of any operational exception. A new version or a run without errors does not, by itself, complete those checks.
Connect release and operational controls
The PolinRider analysis helps distinguish obtaining a package from executing its code. The additional focus here is the automation’s authority to publish an artifact. Pipeline and workstation owners need a shared release identifier, so their decisions do not depend only on a product name or a displayed version.
Keep a dated acceptance record covering versions examined, identities assessed, results and limitations. After pipeline changes, repeat the relevant tests within the authorized scope. That record provides a verifiable basis for resuming work, without treating a signature, provenance or an update as a promise of guaranteed security.
Frequently asked questions
Does the advisory say a patched npm version has been published?
The consulted entry affects 13.3.0 and lists no first patched version. Do not treat the earlier clean version as a published incident fix.
Does Desktop release 0.56.3 prove the device has recovered?
No. Replacing the application and assessing the environment, access and possible persistence are separate checks.
Does valid provenance establish that the content was approved?
It needs to be connected to content review and authorization. The proposed exercise checks that relationship in the business’s own publication workflow.
Does the assessment require installing compromised versions?
No. Use a controlled project, harmless markers and criteria agreed with owners, without reproducing the malicious chain.
Sources and references
- GitHub Advisory Database: malware in bee-js 13.3.0
- Swarm Desktop project: incident note merged in PR 582
- Swarm Desktop project: release 0.56.3, November 9
- SafeDep: bee-js and Swarm Desktop research, November 9
- Socket: release automation analysis, November 9
Original Pentesty analysis, published November 10, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.