critical

CVE

Not assigned

CWE

CWE-494, CWE-506, CWE-522

Affected Surface

  • `feishu-docx-mcp@0.3.2`
  • `bmc-i18n-extract-cli@1.1.1`
  • `blueai-cli@0.7.0`
  • `bmc-translate-utils@1.1.1`
  • Developer workstations and CI runners that installed any of those versions with lifecycle scripts enabled
  • npm publisher accounts, GitHub identities, and local secrets reachable from infected install environments

The freshest supply-chain story in the 5-8 September window is not a brand new worm. It is a return of an old one. On 7 September, four npm packages briefly shipped a payload that Aikido tied to the same Shai-Hulud file hash seen in the 19 May AntV wave. That makes this incident small in package count, but important in what it says about registry trust. A payload that had already been analyzed in public, fingerprinted, and associated with a high-profile 2026 worm campaign still made it onto npm again.

This is also not a duplicate of our earlier AntV Mini Shai-Hulud coverage or the later keyv and cacheable compromise. Those articles cover bigger package sets and broader worm propagation. This one covers a new September registry event with its own package names, publish times, and cleanup sequence.

Affected packages and the registry timeline

The four affected package versions publicly named on 7 September were:

PackageMalicious versionRegistry publish time (UTC)Security holding package time (UTC)
feishu-docx-mcp0.3.22026-09-07T09:25:00.552Z2026-09-07T13:50:30.795Z
bmc-i18n-extract-cli1.1.12026-09-07T09:25:01.459Z2026-09-07T13:50:20.382Z
blueai-cli0.7.02026-09-07T09:25:00.506Z2026-09-07T13:50:14.376Z
bmc-translate-utils1.1.12026-09-07T09:25:00.253Z2026-09-07T13:50:26.598Z

Those timestamps come straight from the npm registry packuments, which now show only the tombstone release line 0.0.1-security as installable. One example is enough to show the pattern:

{
  "dist-tags": {
    "latest": "0.0.1-security"
  },
  "time": {
    "0.3.2": "2026-09-07T09:25:00.552Z",
    "0.0.1-security": "2026-09-07T13:50:30.795Z"
  },
  "versions": {
    "0.0.1-security": {
      "description": "security holding package"
    }
  }
}

That registry state matters for two reasons:

  1. the malicious versions were real and publicly published, not just private telemetry hits
  2. pulling them later does nothing for machines or runners that already executed the install path

GitHub’s malware advisories for all four packages were published at 2026-09-07T13:51:36Z, minutes after the security placeholder packages appeared. In other words, the registry cleanup happened quickly. The exposure window was still large enough for automated installs, CI rebuilds, and broad semver consumers to resolve the bad release.

Why this looks like the same worm family

Aikido’s 7 September analysis makes the family relationship explicit. The payload hash they published for the root-level index.js file is:

e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6

That is the same hash Aikido says it saw in the May 19 AntV wave. Their writeup also says the install path was the familiar one:

preinstall -> bun run index.js
index.js   -> payload sha256 e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6

The rest of the IOC set fits the earlier Shai-Hulud tradecraft as well:

  • t[.]m-kosche[.]com as a network indicator
  • .vscode/tasks.json and .claude/settings.json as persistence-related artifacts
  • npm token validation, tarball download, version bump, and republish logic

That last point is why the package count here understates the operational risk. Four packages is the observed entry point, not the maximum possible blast radius. If one of those installs landed on a maintainer workstation or a privileged CI runner with npm publish access, the worm’s historical pattern is to treat the victim as a stepping stone.

Why the 111-day gap matters

The most interesting part of this story is not sophistication. It is reuse.

By September, the Shai-Hulud family was already public history. Security vendors had written it up. Detection rules existed. npm had also rolled out publish-time malware scanning in July. Yet a payload that Aikido says was byte-identical to the May sample still made it through long enough to become installable.

That makes this a useful case study in what registry-side controls can and cannot promise. An exact-match known sample is the easy case. If that case still reached the registry, defenders should assume that novel one-byte variants, renamed loaders, or slightly shifted install scripts can do the same.

What to check in real code and build systems

Start with lockfiles and manifests:

rg -n 'feishu-docx-mcp|bmc-i18n-extract-cli|blueai-cli|bmc-translate-utils' \
  package-lock.json pnpm-lock.yaml yarn.lock bun.lock . 2>/dev/null

Then look for the family-specific install path and persistence artifacts:

rg -n 'bun run index\\.js|t\\.m-kosche\\.com|Shai-Hulud|\\.claude/settings\\.json|\\.vscode/tasks\\.json' \
  . 2>/dev/null

If your environment keeps extracted package caches, inspect those too. The registry now shows only 0.0.1-security, so post-incident scoping often depends on local artifacts, CI logs, and cached tarballs rather than the current live package page.

Remediation

There is no patched release line for these packages. The GitHub malware advisories mark the safe action clearly: treat the host as compromised if the package was installed or executed.

The response order should be:

  1. isolate the affected workstation or runner
  2. remove the package references from manifests and lockfiles
  3. clear caches and rebuild from a reviewed lockfile on a clean machine
  4. rotate npm, GitHub, cloud, SSH, and other secrets that were reachable from the install context
  5. review publisher accounts and CI identities for follow-on unauthorized releases

This September flare-up is easy to overlook because the package list is short and the bad versions were replaced quickly. That is exactly why it matters. Supply-chain incidents are not only the giant 400-package waves that dominate headlines. Sometimes the higher-signal warning is four quiet packages, one old hash, and proof that a known worm payload can come back months later and still find its way into the registry.

From research to remediation

Check whether this pattern exists in your codebase

Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.

Explore dependency scanning Explore secrets scanning Get Demo

References