The Worst Three Months in npm History: What Your Build Layer Needs When the Registry Can't Be Trusted

Between March and June 2026, four separate supply-chain attacks hit production-critical npm packages: Axios, node-ipc, Red Hat's own @redhat-cloud-services namespace, and the Mastra AI framework's entire scope. None of them was a typosquat. Every one shipped under a legitimate name, signed by infrastructure everyone trusted, and each one defeated a different defense the industry had agreed was sufficient. If you run a git-push platform — anything that npm installs a tenant's dependency tree on every deploy — the registry just spent a quarter proving it is hostile input, not a trusted dependency.

Here is the scoreboard, then what each attack teaches, then the five build-layer controls that survive all four.

Four compromises in 78 days: the scoreboard​

The pattern across the rows matters more than any single row: attackers stopped fighting the registry's defenses and started wearing its uniforms — real maintainer accounts, the real CI pipeline, real provenance signatures. Now the details.

Axios: the maintainer's account was the vulnerability​

On March 30–31, 2026, an attacker took over the npm account of jasonsaayman, Axios's lead maintainer — changing the account email to an anonymous ProtonMail address — and published two malicious releases, axios@1.14.1 and axios@0.30.4, straight through the npm CLI. The attacker's GitHub access let them delete the compromise report a collaborator was trying to respond to, buying quiet time. The poisoned versions were live for roughly three hours before npm pulled them at 03:29 UTC on March 31.

The technique is what makes this one worth studying rather than just patching. Neither malicious version contained hostile code directly. Both quietly added a dependency on a newly published package, plain-crypto-js@4.2.1, which is never imported anywhere in the Axios source — a phantom dependency whose only job was dropping a remote access trojan onto developer machines across macOS, Windows, and Linux.

Sonatype's analysis tracked both versions, Datadog and Snyk (SNYK-JS-AXIOS-15850650) documented the cross-platform RAT, and Dark Reading quoted StepSecurity calling it "among the most operationally sophisticated supply chain attacks ever documented against a top-10 npm package" — it bypassed Axios's OIDC-based publishing pipeline and shipped anti-forensics that made npm list report the wrong version after infection.

The blast radius is the point: Axios's two lines reach up to 100 million weekly downloads (Malwarebytes). Anyone whose package.json carried a caret range like ^1.12.2 with no lockfile — or who regenerated a lockfile during that three-hour window — installed a RAT on npm install. For a PaaS build layer, that is the nightmare shape exactly: a routine tenant redeploy, during an unremarkable three hours, pulling a backdoor into a build container that holds deploy tokens and cloud credentials.

node-ipc: the malware that never ran an install script​

On May 14, 2026, three new node-ipc versions — 9.1.6, 9.2.3, and 12.0.1 — appeared on the registry within minutes of each other. The attacker had re-registered an expired email domain belonging to a maintainer and ridden the password reset into the publishing account. Inside the package's CommonJS bundle sat an 80KB obfuscated credential stealer that fingerprints the host, hunts more than 100 categories of sensitive files — AWS, Azure, and GCP credentials, SSH keys, Kubernetes configs, GitHub and AI-provider tokens — and exfiltrates the haul through DNS TXT queries, not HTTP.

Read that last clause again, because it is the whole lesson. No postinstall hook. No preinstall hook. No HTTP request a firewall or egress proxy would ever see. The payload runs at require() time and phones home over DNS, a channel most build sandboxes leave wide open because package installation itself needs name resolution.

Per The Hacker News, remediation meant pinning back to known-clean versions (9.2.1, 12.0.0), rotating every secret that existed on disk during the window, and auditing cloud logs for what those credentials did while exposed.

This is the attack that kills "--ignore-scripts and we're done" as a complete posture. Disabling install scripts is still the cheapest mitigation in the business — it just isn't a sandbox. node-ipc executed in the most ordinary way a dependency can execute (being imported) and exfiltrated over the most ordinary channel a network has (DNS). May 2026 was a brutal month overall — the same weeks saw TeamPCP's "Mini Shai-Hulud" worm tear through @tanstack/*, Mistral, UiPath, and hundreds more packages — but node-ipc is the one that redrew the boundary of what "install-time defense" has to cover.

Red Hat: the attack with valid provenance​

On June 1, 2026, Wiz Research disclosed "Miasma": 32 packages under Red Hat's official @redhat-cloud-services namespace, across 90+ versions, all carrying a preinstall credential stealer with worm capabilities. The intrusion path, per Red Hat's own bulletin RHSB-2026-006 and Microsoft's analysis, ran through a compromised employee GitHub account pushing unauthorized commits — which the project's legitimate GitHub Actions release workflow then built and published through OIDC trusted publishing, Sigstore provenance and all.

Sit with what that means: the malicious packages carried valid SLSA provenance. Every automated check that asks "was this tarball built by the project's real CI from a real commit?" answered yes, truthfully. Snyk's timeline has the root cause public within an hour of disclosure — compromised employee account, OIDC-published packages with valid provenance — and JFrog stresses this was no typosquat: the packages were trusted delivery vehicles, executing during installation before application code imports anything.

Provenance answers "who built this," not "should you run it." That was always the formal semantics, but Miasma is the incident that made the gap visceral: an enterprise vendor's official namespace, published by its real pipeline, attested by real signatures, installing a credential stealer in your preinstall. Any defense stack that treats a green Sigstore badge as a safety verdict — rather than as one input about build identity — failed open on June 1. (VentureBeat's roundup documents the same lesson from the May OIDC-token thefts: stolen CI identities mint certificates that pass automated verification.)

Mastra: 140 packages poisoned at the registry level​

On June 17, 2026, an attacker using the hijacked npm account of ehindero — a former Mastra contributor whose publish rights across the whole @mastra scope had never been revoked — republished roughly 140 packages in a single burst, injecting a phantom dependency called easy-day-js into every one. The name apes dayjs, the date library with 57M+ weekly downloads; the package itself was a fresh typosquat whose postinstall script was a malware dropper. @mastra/core (around 918K weekly downloads), mastra, and create-mastra all shipped the payload, and the malicious versions became the registry's latest tag — the default target of every fresh install.

Two details elevate this above an ordinary account takeover. First, nothing in the Mastra repositories was malicious: the poison existed only at the registry level, in tarballs that no longer matched any commit. Harness's analysis frames it exactly right — the ecosystem was poisoned at the registry level, so source review of the repo could never have caught it. Second, the publishes went out manually, bypassing the project's normal GitHub Actions release automation — the tell that something was wrong, visible only to someone comparing "how this scope normally ships" against "how it just shipped." Microsoft later attributed the campaign to Sapphire Sleet, a North Korean actor, and per The Hacker News the industry-wide count settled around 145 compromised packages.

Mastra is the scope-blast-radius incident: one stale credential, one burst, an entire framework's install base. It is also the lockfile incident. A frozen lockfile is the only artifact standing between "the registry's latest tag just moved to malware" and your next deploy — and create-mastra scaffolding runs, by definition, resolve fresh.

The build-layer checklist: five controls, mapped to the four attacks​

A git-push PaaS runs npm install on untrusted trees as its core business. Here is the minimum viable build layer after this quarter, with each control tied to the attack that justifies it — including honest notes on what each control does not cover.

Two more items belong on every platform's list even though they are not install controls. Build-environment secret hygiene: every stealer in this quarter hunted exactly what CI holds — npm tokens, cloud credentials, Kubernetes service accounts, GitHub App keys. Scope build secrets to the single deploy, prefer short-lived OIDC-minted credentials over anything that survives in a file, and assume anything on disk during a compromised install is burned. A rehearsed response playbook: pin to known-good versions, rotate every secret present during the window, audit publish activity for scopes your tokens can touch, and review cloud and workflow logs for what stolen credentials did — the node-ipc remediation list generalizes to all four.

Assume the registry is hostile​

Step back and the quarter tells one story. Axios proved account takeover beats pipeline hardening. node-ipc proved import-time code plus DNS beats script blocking. Red Hat proved malicious commits plus a legitimate pipeline beat provenance. Mastra proved stale credentials plus registry-level editing beat source review. Each defense the industry recommended in January had a counterexample by June — not because the defenses are useless, but because each one answers a narrower question than "is this safe to install," and attackers spent three months aiming at exactly the unanswered remainder.

The fix is not a sixth silver bullet. It is the unglamorous stack above: frozen trees, no ambient script execution, no ambient network, identity verification with honest semantics, and a tripwire on every new dependency — plus secret hygiene and a playbook for the day the stack meets something new. None of these controls is exotic. All of them are automatable at the platform layer, which is precisely why they belong in the build system rather than in every tenant's checklist: the team deploying a side project at midnight should inherit them, not configure them.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Build-time sandboxing, frozen lockfile installs, and per-build SBOMs belong in the platform, not in your checklist. Star the repo on GitHub or deploy your first app today.