Shai-Hulud Rises From the Dead after 111 days

What it is

The Shai-Hulud npm worm payload — SHA256 e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6 — reappearing on npm on September 7, 2026, 111 days after the @AntV compromise wave of May 19. Aikido reports this is the longest dormancy-to-reactivation gap they've seen for a Shai-Hulud payload. The republished packages: feishu-docx-mcp@0.3.2, bmc-i18n-extract-cli@1.1.1, blueai-cli@0.7.0, bmc-translate-utils@1.1.1.

How it works

The file is byte-identical to the May sample — not repacked, obfuscated, or modified. Aikido's detection history shows 319 package versions carrying this hash, all first seen on May 19, then zero new hits May 20–September 6, then four on September 7. The infection chain: root-level index.js executed via a preinstall script running bun run index.js; outbound validation calls to the npm registry using stolen tokens; then a tarball download → payload injection → version bump → republish loop. It also mass-creates GitHub repositories with Dune-themed naming and reversed "Shai-Hulud" strings in their descriptions.

Preconditions / Affected

Anyone installing the four listed packages. The self-propagation stage requires a compromised/stolen npm token to republish. Note the persistence targets developer-tooling files (.vscode/tasks.json, .claude/settings.json), so an infected dev machine re-triggers on editor/agent load, not just at install time.

What to do

Block or hunt on these IOCs:

• C2 domain: t[.]m-kosche[.]com
• Hash: e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6
• Package/version pin-outs: the four listed packages
• Persistence files: inspect repos for .vscode/tasks.json and .claude/settings.json you didn't author
• Manifest check: any preinstall running bun run index.js

Aikido's operative recommendation: this exact sample "should be in the testing corpus of anybody doing supply chain scanning." If you run registry- or CI-level scanning, verify this known hash actually gets flagged rather than assuming it does — the whole point of the writeup is that npm's July 2026 publish-time scanner (5–15 min hold per package) did not catch an exact, previously-fingerprinted match.

Caveats

The claim that npm's scanner missed it is Aikido's inference from the payload going live, not a confirmed statement from npm about why. The behavioral indicators (GitHub repo creation, republish loop) are attributed to this payload family; the page doesn't re-verify each behavior against the September samples specifically versus the May analysis. The registry-scanning failure is the story here — the four packages themselves are a small blast radius; the alarming part is what a single-byte change would evade.