Key Takeaways

  • Socket now tracks nearly 12,000 compromised packages every week, up from an earlier baseline of 4,000.
  • Self-propagating package worms like Shai-Hulud have moved from theoretical whitepapers into active production, leaping across npm, Rust, Go, and PHP.
  • Attackers have shifted their focus away from hardened cloud production clusters directly toward developer workstations and automated CI/CD runners.
  • Automated CI runners present the primary vector for cross-registry hopping because build environments carry active publish tokens.

The New Reality of Cross-Registry Worms

For years, software supply chain attacks were discrete events. An attacker compromised an npm account, swapped a library for a trojan, and waited for downstream users to install it. That era is over.

Ahmad Nassri watched this change firsthand as CTO of npm and now at Socket. The attack volume has exploded. “Nowadays, we're seeing close to 12,000, and that number keeps growing, per week,” (play from 1:02:58) Nassri explains. “We're also seeing novel and new type of attacks that are happening.” (play from 1:03:03)

The most dangerous shift is the arrival of autonomous propagation. For years, security researchers modeled worms that could replicate across package managers, but the threat stayed theoretical. That ended recently. As Nassri points out: "Like a year ago, this idea of a worm self-propagating itself across a package registry, it was theorized many, many, many, many, many years ago, but not never actually surfaced, never actually happened. And then all of a sudden, it started with the I think the Shai-Hulud was the first instance of it, I believe. That was a like a self-propagating worm across npm. And then it happened again on npm, I think a third time on npm, and then it started self-replicating across registries."

Once a worm takes root in a developer environment, it does not stop at JavaScript. It sweeps the file system, locates tokens for crates.io, PyPI, or GitHub, and crafts poisoned packages in those adjacent ecosystems within minutes.

Why CI Runners Are the New Endpoint

Most founders spend their engineering security budgets on AWS firewalls, Kubernetes ingress rules, and database encryption. Nassri points out that attackers have already conceded that front. They do not care about your production VPC when your developers hold the keys.

“What we're actually seeing now is all these attacks are targeting the end point, aka the developer machine, the workstations, more so than they're targeting any production environment or any target deployment mechanism,” (play from 1:05:01) Nassri says.

Even worse than local developer laptops are the automated pipelines that test and build code. A developer laptop often prompts for two-factor authentication or hardware keys. A GitHub Actions runner or GitLab CI worker runs headless, packed with elevated access tokens. Nassri notes that cross-registry spreading feeds on these runners: “The jumping from what what we've observed it's happened mostly mostly on, I would say CI. More more instances of that happening on a CI than happening on a local machine.” (play from 1:15:53)

A single poisoned pull request executes arbitrary code inside a CI runner. That runner contains environment variables with deploy keys, registry secrets, and internal repository access. In seconds, the worm harvests those credentials, publishes a new wave of infected packages, and moves to the next company.

What to Do With This

Audit your GitHub Actions secrets today and revoke any static npm, PyPI, or cloud tokens stored in plain repository variables. Replace static publish tokens with short-lived OpenID Connect (OIDC) identities, and lock down CI egress traffic so external network calls require explicit allowlisting.