Researchers report Mini Shai-Hulud hits OpenSearch, Guardrails, and RubyGems after TanStack

• TanStack's initial advisory said 42 @tanstack/* packages, 84 versions total, were compromised within a 10 minute window, with a payload that exfiltrated cloud creds, GitHub tokens, .npmrc contents, and SSH keys, according to TanStack's security advisory.
• By the next day, the campaign expansion report and Guardrails AI's advisory repost tied the same Mini Shai-Hulud campaign to OpenSearch, Guardrails, UiPath, Mistral-related packages, and other ecosystems.
• TanStack's own follow-up shifted the story from one bad package publish to broken publishing machinery: TanStack's hardening follow-up came right after its postmortem, and outside observers like kimmonismus framed that as a compromise of the release pipeline itself.
• The nastiest detail was a dead-man's switch that reportedly polled GitHub and wiped a home directory when a stolen token was revoked, as described in the dead-man's-switch screenshot and amplified by TheZachMueller's repost.
• The immediate fallout is already turning into concrete repo policy: kevinkern's hardening skill enumerated cache review, package-age gates, lockfile hardening, risky dependency specs, and lifecycle-script checks, while dangtony98's credential-brokering thread pushed proxy-attached secrets instead of handing agents raw API keys.

You can read TanStack's postmortem and incident follow-up, inspect the original GitHub security advisory, and compare it with StepSecurity's running campaign write-up. There is also a linked Socket breakdown in TanStack's thread, plus a live example of teams turning the incident into a checklist in kevinkern's repo-hardening skill.

TanStack's advisory was the clean starting point: 42 packages, 84 malicious versions, two bad publishes per package, all pushed in a short window on May 11 TanStack's security advisory.

By May 12, the story was no longer just about TanStack. the campaign expansion report said Mini Shai-Hulud had also hit OpenSearch, Mistral AI, Guardrails AI, UiPath, and other packages across npm and PyPI.

Guardrails became one of the first named follow-on victims in the evidence pool. ShreyaR's repost of Guardrails AI's advisory said the open source guardrails-ai 0.10.1 release had been compromised as part of the same campaign.

A separate screenshot in the Mistral package issue screenshot showed a GitHub issue claiming @mistralai/mistralai was part of the latest Shai Hulud worm. That fits the pattern in the expansion reports, but it is still a community report in the evidence here, not a vendor postmortem.

TanStack published an official postmortem first, then a separate hardening follow-up the next day. The sequence matters, because the second post suggests the team treated this as a CI and publishing-path failure, not just a one-off bad package upload.

The most pointed public question came from cramforce's cache-poisoning question, which asked how the attack bypassed GitHub's default ref-scoped caches. That lines up with why this incident got so much attention from build engineers: it hinted that default CI assumptions were not enough.

Outside commentary converged on the same framing. matteocollina's repost thread called the compromise a lesson in why trusted publishing is not enough, while kimmonismus reduced it to one sentence: the attack compromised the machinery that ships packages.

That also explains why TanStack's own follow-up tweets emphasized security audits across CI/CD pipelines on Devtools and AI repos, according to AlemTuzlak's audit update.

The payload detail that spread fastest was not exfiltration. It was retaliation.

According to the carlini screenshot embedded in a repost, the malware installed a watcher as a systemd user service on Linux or a LaunchAgent on macOS, polled api.github.com/user every 60 seconds with the stolen token, and ran rm -rf ~/. if the token started returning 40x responses. TheZachMueller's repost summarized the same behavior as a dead-man's switch that would wipe your computer if you revoked the stolen GitHub token.

That changes the incident-response sequence in a nasty way. Revoking a token is normally the first reflex after credential theft. Here, the revocation itself was reported as the trigger for destructive behavior.

A later practitioner complaint from RayFernando1337's blocked Anthropic screenshot showed another side effect of this kind of attack wave: he said Anthropic blocked a request to check whether his own laptop was safe, while his GPT-5.5 comparison screenshot showed another model proceeding with an audit plan against the home directory.

The fastest useful output after the incident was not another hot take. It was a hardening checklist.

kevinkern's skill post condensed the first-pass checks into a scan that looks for:

• pnpm 11+ package-manager policy
• release-age gates and lockfile hardening
• risky dependency specs such as latest, git, http, and file:
• unreviewed dependency lifecycle scripts
• unsafe CI install, cache, publish, and secret patterns
• optional npm supply-chain incident checks

The screenshot attached to that scan output is useful because it shows what this looks like in practice. It flagged root postinstall, CI installs that still run scripts, a legacy pnpm pin, 118 floating direct dependency specs, npm install -g inside release workflows, and CI cache usage that still needed cache-poisoning review.

The lighter-weight policy shift also showed up in reactions around minimum package age. dabit3's repost of Ryan Carson pushed a minimum-age rule for installs, and nicopreme's repost of RhysSullivan said they had enabled one on their own machine.

The campaign did not stay confined to package hygiene. It spilled straight into secrets design.

In a thread reacting to a separate RubyGems incident, dangtony98 said more than 120 malicious gems had been pulled after silently harvesting SSH keys, API tokens, and credentials on install. The throughline in that thread was simple: once registries and build paths are compromised, central secret storage by itself is not the end of the problem.

That is where the thread started pushing two concrete product ideas. dangtony98's honey-token post pitched fake credentials planted next to real ones as breach tripwires, and dangtony98's credential-brokering explanation described a proxy model where a sandboxed agent never receives raw Anthropic or GitHub keys at all.

The mechanics in that thread are specific enough to matter. The agent makes outbound requests through a dedicated proxy service, and the proxy attaches credentials on the way out. a follow-up preview of Agent Vault framed that as credential brokering for agents, and another short post reduced the developer ergonomics pitch to a single command wrapper: infisical run -- npm run dev.

That does not fix cache poisoning, malicious tarballs, or compromised publish paths. It does add one new fact at the end of this story: the fastest security product response to Mini Shai-Hulud is already shifting from storage to brokering, because the secret that never lands on the box is the one the package cannot steal.