Two npm Supply-Chain Campaigns Run Simultaneously: A Rust-Based eBPF Stealer and a Self-Spreading Worm

The npm Registry Is Under Attack From Two Directions at Once

JFrog researchers have identified two simultaneous supply-chain campaigns operating inside the npm registry, with one deploying a Rust-built credential stealer backed by a kernel-level rootkit and the other acting as a self-replicating worm that has already poisoned more than 50 packages.

Both campaigns are live. Both are dangerous. And neither required npm's publish infrastructure to fail in any traditional sense — the attackers used the system exactly as designed.

Campaign One: A Stealer That Hides in the Kernel

The first campaign delivers a Rust-based information stealer that does something most endpoint tools are structurally unprepared to catch. After landing on a developer's machine, it begins scraping credentials, authentication tokens, and configuration secrets. Then it pulls a technique almost entirely absent from commodity malware until roughly 18 months ago: it deploys an eBPF kernel rootkit.

eBPF, or extended Berkeley Packet Filter, is a technology that allows programs to run sandboxed code directly inside the Linux kernel. Security and observability tools have used it for years. Attackers are now using it too. By installing hooks at the kernel level, this stealer can selectively falsify what the operating system reports to userland tools — file listings, running processes, network connections. An endpoint agent reading from `/proc` or relying on standard syscall tracing can be told a clean lie.

The practical implication is severe. Most commercial EDR and SIEM products still collect telemetry through interfaces that a well-placed eBPF hook can manipulate. Defenders who want to detect this class of threat should run `bpftool prog list` on Linux hosts and compare output against a trusted baseline. Anything unexpected deserves immediate investigation.

Campaign Two: The Worm That Feeds on Publish Tokens

The second campaign is structurally simpler but scales faster. Once installed on a developer's system, it searches for stored npm credentials — the tokens developers use to publish packages — and uses them to push trojanized versions of every package that maintainer controls. That single mechanic explains why the affected package count crossed 50 so quickly. The worm finds legitimate, trusted packages and turns them into delivery vehicles.

This propagation pattern is not new. A similar technique appeared earlier this year in the activity researchers called Shai-Hulud. What has not changed since then is the underlying policy gap: npm's publish workflow still treats a valid token as proof of valid intent. There is no out-of-band confirmation step when a new version appears on an established, widely-downloaded package. A stolen token is, from the registry's perspective, indistinguishable from a legitimate release.

This is the kind of gap that security-awareness training directly addresses. A developer who understands token hygiene — rotating credentials regularly, storing tokens in secrets managers rather than dotfiles, recognizing that a compromised workstation puts every package they maintain at risk — represents a substantially harder target than one who treats publish tokens as permanent fixtures.

What the Regulatory Frameworks Say (and Don't Say)

The CISA Secure Software Development Attestation framework requires federal software producers to attest to controls over build environments and developer credentials. The EU Cyber Resilience Act imposes vulnerability handling obligations under Article 13, phasing in through 2026. Both frameworks push accountability toward software producers and downstream consumers.

Neither, however, currently compels a registry operator like npm to enforce stronger publishing controls — mandatory two-factor confirmation on version bumps, for instance, or behavioral analysis of package diffs before a release goes live. That gap is where both campaigns operate.

No CVE identifiers have been assigned to the malicious packages. MITRE has historically not issued CVEs for registry-side compromises of this type. Defenders should track affected package names and version ranges from JFrog's advisory and pull them from internal artifact mirrors immediately.

The question of whether package registries should be designated critical infrastructure under sector-specific rules is unresolved. CISA has not proposed such a designation. Industry comment submitted during the CIRCIA reporting rule window — which closed July 3, 2024 — was split on the question. It will return.

The Control Failures That Made This Possible

Two failures enabled these campaigns, and they are worth naming precisely because they are not exotic.

First: developer workstations are treated as trusted environments. They are not. A developer machine is a high-value target precisely because it holds credentials for build systems, cloud environments, and package registries. The moment malware lands on that machine, every token stored in a dotfile, a shell history entry, or an unencrypted credential store becomes a potential attack path. The eBPF rootkit compounds this by ensuring the compromise stays invisible longer, widening the window between infection and detection.

Second: publish tokens are not rotated. The Verizon 2024 Data Breach Investigations Report found that stolen credentials remain the single most common initial access vector, appearing in 77% of web application breaches. Tokens that have never been rotated and live on multiple machines represent exactly the credential surface this worm was built to exploit. Rotating any npm publish token that has touched a developer workstation in the past 30 days is not optional at this point — it is baseline hygiene.

Organizations that have not already moved to pinning dependencies by integrity hash rather than semver range should treat this incident as the forcing function. A worm that republishes trojanized versions of legitimate packages under the same package name and a higher version number will satisfy a `^` or `~` version range automatically. Hash pinning breaks that mechanic entirely.

For teams reviewing their security standards and compliance posture, these campaigns illustrate a pattern that regulators are increasingly watching: software supply chain attacks that succeed not through zero-days, but through ordinary credential mismanagement amplified by poor registry policy.

What Defenders Should Do Right Now

• Audit all Linux developer hosts for unexpected eBPF programs using `bpftool prog list` against a known-good baseline.
• Rotate every npm publish token, especially those stored in dotfiles or shared across workstations.
• Pin all npm dependencies by integrity hash (use `npm shrinkwrap` or lockfile integrity fields) rather than accepting semver ranges.
• Pull JFrog's list of affected package names and versions, and block or remove them from internal artifact mirrors.
• Review your organization's software attestation posture against CISA's Secure Software Development Attestation form before consuming or distributing any npm packages flagged in this campaign.

Teams looking at security awareness training options should consider that developer-focused modules — covering token hygiene, supply chain risk, and workstation security — are among the highest-leverage investments an organization can make against this class of threat.

The npm registry processes millions of package downloads daily. Two campaigns running concurrently, one invisible to most EDR tooling, represent a meaningful moment. The registry's gatekeeping failed not because of a software vulnerability, but because a valid token still means the door opens. That is a policy decision, and it is one the industry has not yet resolved.