npm Hit by Dual Supply-Chain Campaigns: Rust Stealer With eBPF Rootkit, Self-Spreading Worm

Two distinct supply-chain campaigns are running concurrently inside the npm registry, and the registry's gatekeeping is once again the story.

Researchers at JFrog identified the activity, attributing the first cluster to a Rust-based information stealer and the second to a self-replicating worm that has compromised, or impersonated, more than 50 legitimate packages.

The stealer is the more technically notable of the two. It scrapes credentials, tokens and configuration secrets from a developer machine, then conceals its presence using an eBPF kernel rootkit — a technique that has migrated steadily out of red-team research and into commodity malware over the past eighteen months. Kernel-resident hooks on Linux mean that file listings, process enumeration and network telemetry collected from userland can be selectively lied to. Endpoint agents that depend on /proc or standard syscall tracing are at a structural disadvantage here.

The second campaign behaves like a worm. Once installed, it searches for npm credentials on the host and republishes trojanized versions of any package the victim maintainer controls. That mechanic is what produced the count of fifty-plus affected packages so quickly. It is the same propagation pattern observed in the Shai-Hulud activity earlier this year, and it raises the same unresolved policy question: npm's publish flow still treats a valid token as a valid intent to publish, with no out-of-band confirmation for version bumps on established packages.

That gap sits squarely inside the scope of the CISA Secure Software Development Attestation regime, which requires federal software producers to attest to controls over build environments and developer credentials. It is also relevant to the EU Cyber Resilience Act, whose vulnerability handling obligations under Article 13 begin applying in stages through 2026. Neither framework yet compels a registry operator to enforce stronger publishing controls, but both push liability toward downstream consumers who ingest compromised artifacts.

No CVE identifiers have been assigned to the malicious packages themselves, which is consistent with how MITRE has historically treated registry-side compromises. Defenders should instead track the package names and version ranges published in vendor advisories and pull them from internal mirrors.

Practical guidance is narrow but firm.

Rotate any npm publish tokens that have touched a developer workstation in the past 30 days. Pin dependencies by integrity hash rather than semver range. Audit Linux hosts for unexpected eBPF programs using bpftool prog list, and compare against a known baseline.

The broader regulatory conversation — whether package registries should be designated critical infrastructure under sector-specific rules — remains open. CISA has not proposed such a designation. Industry comment on the question, raised during the CIRCIA reporting rule comment window that closed July 3, 2024, was mixed. Expect it to return.