On 7 September 2026, four npm packages went live within the same hour, each carrying a payload file-hash-identical to the Shai-Hulud worm that compromised 319 package versions back in May. The packages are feishu-docx-mcp@0.3.2, bmc-i18n-extract-cli@1.1.1, blueai-cli@0.7.0 and bmc-translate-utils@1.1.1. Aikido Security found them. The detail that should worry you more than the four packages themselves: npm's own automated publish-time malware scanning had already fingerprinted this exact payload from the May campaign, and it still let the September republish through.
That's a different problem from npm's separate, recent move to retire "bypass-2FA" tokens, which is a credential and access-control policy change. This is a detection gap: a payload the platform already knew was malicious got published again, and the scanner meant specifically to catch known threats didn't catch it.
What Shai-Hulud actually is
Shai-Hulud is the name given to a worm-style supply chain campaign first identified on 19 May 2026, which spread by compromising legitimate npm packages and using them to compromise further packages, eventually touching 319 package versions. The September packages Aikido found carry a payload matching that campaign's file hash exactly, meaning this isn't a new strain that merely resembles the old one. It's the same code, republished under new package names, four different packages, all within a single hour, which points to automated or scripted publishing rather than one person manually uploading each package by hand.
Why the scanner miss matters more than the packages themselves
Four specific malicious packages are straightforward to deal with once you know their names: remove them, block them, move on. A payload that npm's scanning system had already fingerprinted from a prior campaign getting past that same system on republish is a different kind of problem, because it means "it's on npm and npm scans for malware" isn't a safe assumption to build your supply chain security on. If a known-bad payload can slip through, an unknown one has an even easier path in.
What to check right now
Search your lockfiles and package.json files across every project and every environment for feishu-docx-mcp, bmc-i18n-extract-cli, blueai-cli and bmc-translate-utils, including as transitive dependencies pulled in by something else you depend on. Don't stop at direct dependencies. Run a full dependency tree search, since worm-style campaigns are designed to spread through exactly the packages you didn't deliberately choose. It's also worth checking whether anything in your dependency tree traces back to the same author accounts, since Aikido's finding suggests those accounts are actively being used to push this payload under new names.
If you find any of the four packages anywhere in your tree, treat it as a live compromise rather than a routine cleanup: remove it, rotate any credentials or tokens accessible to processes that ran in that environment, whether CI runners, build servers or developer machines, and check for anything the payload might have exfiltrated before you noticed it.
Don't rely on npm's scanning alone
This incident is a concrete argument for running your own dependency scanning rather than treating registry-level scanning as sufficient on its own. Tools like Socket and Aikido itself scan packages for suspicious behaviour independently of npm's own checks, and layering that kind of scanning into your CI pipeline gives you a second chance to catch something the registry missed, which is exactly what happened here.
It's also a reason to be more careful about how dependency updates land in your codebase in the first place. If your CI auto-merges Dependabot or Renovate pull requests without any human or automated second look, or your lockfile tracks loosely pinned version ranges that let new package versions in automatically, you have far less time between a malicious package being published and it landing in your build than a team that pins versions and reviews updates before merging. Neither approach makes you immune, but automatic, unreviewed ingestion of new package versions is precisely the path this kind of campaign is built to exploit.
The bottom line
Four npm packages published on 7 September 2026 carried a payload identical to May's Shai-Hulud worm, and npm's own malware scanning missed a payload it had already fingerprinted once before. Search your dependency tree today for feishu-docx-mcp, bmc-i18n-extract-cli, blueai-cli and bmc-translate-utils, and add independent dependency scanning rather than relying on the registry's checks alone.