On 7 September 2026 Aikido Security reported that four npm packages, published within the same hour by the same npm account, carried a Shai-Hulud payload with the same SHA256 as the one used in the @antv compromise of 19 May 2026. Aikido's records show no sightings of that hash between 20 May and 6 September, a gap it counts as 111 days.
The part worth your attention is not the payload, which Aikido calls the identical file. It is that a known sample was published again and was not stopped by registry scanning that npm had introduced in July.
What happened
Aikido's account, by Charlie Eriksen, gives these facts:
- On 19 May 2026 a compromised maintainer account pushed 639 malicious @antv versions in about an hour.
- On 7 September 2026 four packages appeared with the same payload:
feishu-docx-mcp@0.3.2,bmc-i18n-extract-cli@1.1.1,blueai-cli@0.7.0andbmc-translate-utils@1.1.1. - The payload hash is
e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6. Aikido counts 319 package versions with that hash, all first seen on 19 May. - The package carries a root level
index.jsand a preinstall script that runsbun run index.js.
Aikido lists persistence in .vscode/tasks.json and .claude/settings.json, outbound validation calls to the npm registry with stolen tokens, and the creation of GitHub repositories with Dune themed names. The command and control domain it lists from the May wave is t.m-kosche.com.
Confirmed, reported and unknown
Confirmed by Aikido's own data: the four versions above, the shared hash, the single publishing account and the one hour window.
Reported by Aikido as its interpretation: that this is the longest dormancy to reactivation gap it has seen from a Shai-Hulud payload, and that npm's publish time malware scanning, which holds packages for 5 to 15 minutes, should have caught an exact hash match.
Unknown, because the post does not say: how the publishing account was accessed, why the scan missed the file, whether more than these four packages were published, and what the operator intended.
What to do now
- Search lockfiles and CI caches for the four package names and versions.
- If any machine or runner installed one, treat every secret reachable from it as exposed. Rotate npm, GitHub and cloud credentials, starting with npm tokens.
- Look for
bunruns inside install steps, and for.vscode/tasks.jsonor.claude/settings.jsonfiles you did not write. - Check GitHub for new repositories in your accounts with reversed "Shai-Hulud" strings in the description.
- Block
t.m-kosche.comat DNS and egress and review logs for it.
How this could have been avoided
- Delay adoption of brand new versions. A cooldown of a few days on packages first published within the last week would have kept all four versions out of most builds while detection caught up.
- Block lifecycle scripts for packages that do not need them. These versions ran through a preinstall script, so
ignore-scripts=truein.npmrcin CI stops that route. - Add an exact hash blocklist to your install gate. A file hash match is a lookup, and Aikido's point is that it should never be missed.
- Remove long lived npm tokens from developer machines. Stolen tokens are how this worm republishes itself.
- Alert on a build runner starting
bunornodeprocesses that reach unfamiliar domains.
Try it yourself
Run your lockfile through the free in-browser scan at https://gold.safeguard.sh/scan, then walk through the typosquat and malware demo to see what a first look at a suspicious package shows.
Click through it at your own pace, or open it full screen.
Quick check
Why does the 111 day gap matter?
It shows that a payload quiet for months can return unchanged. Detection that only looks at recent campaigns, or only at behavior, misses a plain known hash.
Which fact does Aikido's post not establish?
How the publishing account was obtained. Do not assume tokens were stolen again.
