Notifications
Clear all
Topic starter
02/08/2026 9:47 am
TL;DR: Shai-Hulud’s latest variant spreads beyond npm installs into GitHub Actions cache poisoning, repo commits, and IDE persistence hooks while also expanding credential theft across cloud, AI, and communication tooling, according to Semgrep. That shift turns developer workspaces and CI pipelines into NHI attack surfaces that conventional secrets hygiene alone cannot contain.
NHIMG editorial — based on content published by Semgrep: Children of Shai-Hulud, an analysis of the TanStack Shai-Hulud campaign
By the numbers:
- The campaign published 84 malicious packages in under six minutes.
Questions worth separating out
Q: What fails when GitHub Actions workflows can be modified to run attacker-controlled code?
A: The failure is trust in the workflow file as a safe automation boundary.
Q: Why do short-lived tokens still create major risk in CI/CD environments
A: Short-lived tokens reduce persistence, but they do not prevent theft during execution or over-privileged use inside the session.
Q: What do security teams get wrong about supply chain malware persistence
A: They often focus only on package registry poisoning and miss local execution state.
Practitioner guidance
- Audit GitHub Actions trust boundaries Review workflows that use pull_request_target, cache restore, or id-token: write permissions.
- Inventory and rotate exposed NHIs immediately Search for AWS, Kubernetes, Vault, npm, GitHub, and AI tooling tokens referenced in runner logs, developer home directories, and repo history.
- Treat developer tooling files as detection signals Add monitoring for .claude settings, .vscode tasks, repo hooks, and unexpected commits to package manifests or setup scripts.
What's in the full report
Semgrep's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step breakdown of the TanStack compromise chain across pull_request_target, cache poisoning, and release workflow abuse
- File-by-file indicators showing how the malware persists in .claude and .vscode configuration paths
- Package namespace and versioning patterns that help teams identify downstream compromise faster
- Detection and response notes for runner memory extraction, token theft, and trusted publisher abuse
👉 Read Semgrep's analysis of the TanStack Shai-Hulud campaign and GitHub pivot →
Shai-Hulud’s GitHub pivot: what does it mean for NHI governance?
Explore further
02/08/2026 12:39 pm
GitHub workflow trust has become an NHI governance problem. This campaign shows that CI/CD identities are not just implementation details. They are privileged non-human identities with publishing authority, repository write access, and token minting power. OWASP-NHI and NIST CSF both become relevant because the control failure is not a single secret leak, but an over-trusted automation boundary that can be turned into a distribution system. Practitioners should treat workflow identity as a first-class governance object.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable when CI identities are abused to publish malicious packages
A: Accountability sits with the teams that own workflow design, package release permissions, and identity governance for automation. In practice, that means engineering, platform security, and IAM must share control over who can publish, what can run, and which tokens can be minted. Frameworks such as NIST CSF and OWASP-NHI help structure that ownership.
👉 Read our full editorial: Shai-Hulud’s GitHub pivot shows why NHI controls lag
