The npm "worms", in plain terms: what happened, and why GeneXus leaves less to get in through

It happened again over the last few weeks, and not for the first time: a "worm" wriggled into software libraries that thousands of companies depend on, stole credentials, and republished itself across more and more packages. It wasn't a noisy attack that "took down" sites with traffic — it was quieter and more expensive. Whole teams had to freeze deployments, pull services out of production as a precaution, and rotate every secret in a hurry while they cleaned up the mess. If you work with GeneXus, it's worth understanding what happened, and why the way you build leaves you less exposed.

This post isn't fear marketing. It's an honest explainer: what a supply-chain worm is, why it spreads the way it does, and where the GeneXus model — and the way KBbridge adds AI — cuts down the surface these things get in through.

What happened, without the jargon

Picture modern software as a piece of furniture assembled from prefab parts: instead of machining every screw, you download it from a giant shared shelf of free parts. In the JavaScript world that shelf is called npm, and a typical project pulls in hundreds or thousands of those parts. Many of them, on top of that, run a small script automatically the moment you install them.

A supply-chain worm exploits exactly that:

1. The attacker phishes whoever maintains a popular part and steals their credentials.
2. They publish a "poisoned" version of that part.
3. When someone installs it, the script steals the tokens and keys on that machine (npm, GitHub, AWS, Azure, GCP, SSH…).
4. With those stolen credentials it publishes poisoned versions of every part it can now touch — and the cycle repeats on its own. That's what makes it a worm: it reproduces with no one pushing it.

The short timeline of what we saw:

• September 2025 — "Shai-Hulud" (named after the sandworm in Dune). The first truly self-replicating one: it compromised more than 500 packages, including @ctrl/tinycolor, used by thousands of projects. CISA issued an official alert.
• November 2025 — "Shai-Hulud 2.0". A far more aggressive variant; more than 25,000 repositories were reported exposed.
• June 1–2, 2026 — "Miasma" (Red Hat). Compromised 32 packages (90+ versions) under the @redhat-cloud-services scope. It stole cloud credentials and even scraped CI/CD runner memory for secrets, republishing with forged provenance signatures.
• June 3–4, 2026 — "Phantom Gyp" / node-gyp. 57 packages poisoned in under two hours. The clever bit: instead of the install scripts security tools watch, it hid execution inside binding.gyp, a build-config file — to stay under the radar.

The pattern is always the same: one stolen credential becomes a cascade.

Why it spreads like this: the root of the problem

These worms aren't magic. They lean on three things stacked together, inherent to building software from public package registries:

• A public registry anyone can publish to. Trust is "open by default."
• Transitive dependencies. Your app uses part A, which uses B, which uses C… You end up trusting thousands of authors you never chose or reviewed.
• Automatic code execution at install or build time. A package can run scripts on your machine just by being installed. Add CI/CD tokens with publish rights, and a single stolen credential is enough to light the fire.

None of the three is a one-off "bug" you patch — it's the model. That's why the moment one variant is contained, another shows up.

Why building on GeneXus shrinks the surface

Here's the part the GeneXus community should keep clear. GeneXus doesn't build your application by gluing together parts from a public shelf:

• It's model-driven. You describe your application in the Knowledge Base, and GeneXus generates the code. You don't assemble your business from hundreds of community packages that run scripts on their own.
• The framework comes from one vendor, curated and versioned — not from a sprawling tree of transitive dependencies no one looked at. The worm's main highway (npm install pulling self-executing code) simply isn't how a GeneXus app is built.
• Your business logic lives in the KB, not scattered across third parties' package.json.

Let's be honest: no software is immune, and a generated front-end can touch some ecosystem package. But the difference in attack surface is enormous. Reviewing the dependencies you choose is one thing; inheriting the trust of thousands of anonymous maintainers is something else entirely.

And when you add AI, KBbridge doesn't open a new door

This is the subtle point, and it's where most of the risk lives today. Wiring AI into your development can be exactly the moment you import npm's threat model: a huge number of AI tools and MCP servers ship as packages you install and that execute code. Bringing AI in that way reopens the very same door.

KBbridge is designed so that doesn't happen:

• Your KB is externalized to plain text in your own Git repository — not published to a public registry where a worm could grab it or republish it. Your intellectual property never lands on that shared shelf.
• The documentation engine is 100% offline. The local MCP server holds 46,750 chunks of GeneXus documentation indexed on your machine: no API keys, no outbound network traffic, nothing downloaded from a registry at runtime.
• You can give the AI real tools without entering the npm ecosystem. With a simple prompt, connecting Claude to KB Editor, I built an MCP server in about 6 hours, generated directly in GeneXus, with no need for Node.js or Python. That means extending your AI with GeneXus itself, not with self-executing third-party packages.
• You choose the LLM, including a self-hosted or air-gapped one. In that scenario nothing leaves your network: not the code, not the KB, not the prompts.
• Plain text in Git = every change is an auditable commit. If anything ever tried to slip in, you'd see it in the diff, in review, like any other change. No opaque binaries, no invisible dependencies.

The underlying idea is the same as always: your business knowledge is yours, and it should stay yours in the age of AI — without, along the way, opening the door these worms come in through.

The questions worth asking

If you're weighing how to add AI to your development — with any tool — these are the questions that matter:

• Is my app assembled by installing hundreds of packages from a public registry? With GeneXus, no: the code is generated from your model.
• Does the AI tool force me to install packages that execute code? With KBbridge, no: the docs engine is offline, and you can generate your MCP servers in GeneXus.
• Does my KB leave my infrastructure? Only if you decide so, to the provider you choose — or to none, if you run a local model.
• Can I audit every change? Yes: with Git, commit by commit, with author and diff.

Sources

So you can read it first-hand, not through our interpretation:

• CISA — Widespread Supply Chain Compromise Impacting npm Ecosystem
• Palo Alto Unit 42 — "Shai-Hulud" Worm Compromises npm Ecosystem
• Wiz — Shai-Hulud 2.0: Ongoing Supply Chain Attack
• StepSecurity — Shai-Hulud: Self-Replicating Worm Compromises 500+ npm Packages
• Microsoft Security — Inside the Red Hat npm "Miasma" credential-stealing campaign
• Snyk — node-gyp / binding.gyp self-propagating npm worm ("Phantom Gyp")
• The Hacker News — IronWorm and new Miasma worm variant hit npm

Want to see what working with AI on a GeneXus KB looks like without opening that door? Watch the short videos on Getting Started, or try it free for 15 days, no card required, at kbbridge.com.