npm’s long-awaited v12 won’t close the gaps that matter most: account takeover, native builds, or detection of malicious intent at publish time. Closing those gaps is squarely on Microsoft.
Threat actors act like small startups, they are hungry for success, constantly adapting, and move really fast. During the last week we’ve seen another two instances of successful Shai-Hulud (or Miasma or Hades) variants supply chain attacks on npm.
The Variants Keep Getting Smarter
With over 15 distinct campaigns these variants and their predecessors have taken over the supply chain world: The Shai-Hulud supply chain malwares are not just regular malware. They self-replicate, they are highly stealthy, and their actors elevate their techniques on every iteration. Each wave gets harder to detect, more persistent, and more dangerous than the last.
What makes the latest wave particularly alarming is how rapidly the techniques themselves are evolving. Threat actors are now actively detecting and evading security infrastructure, identifying StepSecurity domains and sandboxes and falling back to DNS-based exfiltration when conventional channels are blocked. They’ve learned to hide in plain sight, abusing legitimate platforms like GitHub and Hugging Face as C2 servers, and uploading stolen credentials directly into GitHub repositories, blending malicious traffic with the noise of normal developer activity.
They’ve weaponized the supply chain’s own infrastructure against it, using compromised JFrog API keys to deliver further npm malware downstream. And their target selection has grown bolder: these aren’t opportunistic hits on small projects anymore. This includes successfully breaching GitHub repositories, Microsoft Azure, Aqua Security, Checkmarx, SAP, and Mistral AI: organizations that, by all accounts, should be among the hardest to compromise.
Even after detection, infected machines and accounts can’t be cleaned easily. Tokens are being monitored for revocation, endangering the host’s filesystem, and the malware tries to persist by infecting your IDEs, your coding agents, your GitHub actions, and more.
It is also concerning that threat actors are consistently successful with these supply chain malware attacks. They took over legitimate npm packages everyone trusts and made them part of the attack. Over the course of a few months they compromised highly popular packages and large organizations such as CrowdStrike, Zapier, Aqua Security, LiteLLM, Axios, Telnyx, Bitwarden, SAP, PyTorch Lightning, TanStack, Microsoft, Red Hat.
Why npm Always Arrives Late
While attackers act like start-ups and move fast, our defenses act like big corporations: they are very slow to respond, have a lot of bureaucracy, and generally can’t do much in a short period of time.
When npm announces features involving security or supply chain integrity, they often arrive months – sometimes years – after the threats they’re meant to address have already evolved past them.
This problem is compounded by how long malware stays live after publication. In one recent Shai-Hulud-related incident, a developer affected by a compromised account told us npm support took close to 24 hours to respond, while the account remained compromised the entire time.
Innovation has found its home in the wrong camp.
v12 Is a Real Fix. It’s Also Not Enough
Recently, following the wave of Shai-Hulud incidents, GitHub announced that npm v12 — expected in July 2026 — will introduce several security-focused breaking changes aimed at blocking supply chain attacks that abuse behaviors triggered by npm install. Specifically, install scripts will no longer run automatically, Git dependencies will be blocked by default, and remote URL dependencies will require explicit opt-in — a fundamental shift from implicit trust to explicit approval.
But without malware detection capabilities, these attacks can’t be stopped completely. Account takeover remains an open wound. Once an actor controls a legitimate maintainer’s credentials, no amount of install-script blocking helps, because the malicious code ships as a trusted, signed release. And even npm v12’s headline feature can be bypassed: binding.gyp files trigger native builds through node-gyp, which npm treats as a first-class citizen rather than a lifecycle script — meaning malicious native code executes on install regardless of the new defaults.
The deepest problem isn’t even at install time. Even if every postinstall hook is stripped, silenced, and sandboxed, actors can still execute arbitrary commands the moment their compromised module is require()’d or import’ed — no scripts needed, no user approval prompt, nothing.
A Case Study: anthropic-internal-tools
One good example of why malware analysis and code review matter for npm packages: a package we identified last week called “anthropic-internal-tools.” Its developers didn’t even try to hide their intent. Beyond the obvious Anthropic impersonation in the name, the package contains hardcoded, cleartext evidence of its credential-stealing logic, including a function named “exfil,” a string reading “dependency_confusion_beacon,” and a full list of sensitive files and environment variables built for exfiltration.
The Fix Has to Live Inside the Platform
npm must start treating malicious code and malicious intent the way social media platforms treat offensive content. Until then, the registry will keep getting flooded with malicious packages, and developers will be the ones asked to inspect packages and sub-dependencies before installing, and sandbox anything they can’t fully vet.
That’s a heavy ask. Not every developer works in security, and not everyone tracks these incidents as they happen or has the tooling to rotate keys, clean infected configurations, and run a full recon of their own machine after the fact. The industry can build detection and response tools from the outside, but only for the subset of developers who already use them. Most won’t.
That asymmetry is why the fix has to live inside the platform itself, not around it.
Microsoft owns npm through its ownership of GitHub, and with that ownership comes responsibility for the registry’s security posture. The fixes coming in v12 are a start, but they don’t touch account takeover, native builds, or detection of malicious intent at publish time. Closing those gaps is squarely Microsoft’s to do, because no amount of external tooling reaches every developer who pulls a package from npm. The platform that everyone depends on has to be the one that defends them.
