--- title: "Starving Shai-Hulud" description: "The Shai-Hulud npm worm keeps coming back for developer credentials. Here is how Santa file access rules cut off its harvest." doc_version: "1" last_updated: "2026-10-30" canonical: "https://northpole.security/blog/starving-shai-hulud" --- [Back](https://northpole.security/blog) Guides • October 28, 2026 • By Ian Langworth ![Starving Shai-Hulud](https://northpole.security/images/blog/starving-shai-hulud-hero.jpg) ![](https://northpole.security/images/home/divider-band-top.svg) Shai-Hulud, the npm worm named after the sandworms in Dune, refuses to stay dead. The first wave hit in September 2025 when [`@ctrl/tinycolor` and hundreds of other npm packages](https://www.stepsecurity.io/blog/ctrl-tinycolor-and-40-npm-packages-compromised) were compromised. The “Second Coming” followed in November 2025, which hijacked packages from Zapier, PostHog, Postman, and AsyncAPI, and seeded [roughly 25,000 GitHub repositories](https://blog.checkpoint.com/research/shai-hulud-2-0-inside-the-second-coming-the-most-aggressive-npm-supply-chain-attack-of-2025/) with stolen secrets. In April, Bitwarden’s CLI and SAP npm packages were affected. In May, there were three more waves in nine days: “Mini Shai-Hulud” spread through the [TanStack dependency tree](https://www.akamai.com/blog/security-research/mini-shai-hulud-worm-returns-goes-public) on May 11th, a compromised version of the Nx Console VS Code extension (an extension with 2M+ installs) carried a related payload for a roughly 18-minute window on May 18, and an attack on the [AntV ecosystem](https://www.stepsecurity.io/blog/shai-hulud-here-we-go-again-mass-npm-supply-chain-attack-hits-the-antv-ecosystem) compromised ~300 packages on May 19. The worm’s full source code was released publicly on May 12, and copycats followed within weeks. In July, IronWorm, a Rust-based worm similar to Shai-Hulud, stole local 1Password and Bitwarden vaults. In August, ChainDrop compromised 400+ packages, and then the Tensorlake package was compromised similarly in October. Every wave runs the same playbook. First, get code running on a developer machine through an npm lifecycle script (disabled by default since npm 12), a trojaned extension, or just code that runs on module load. Then harvest every credential in reach, exfiltrate, and use the stolen tokens to propagate. [StepSecurity’s teardown of the Nx Console payload](https://www.stepsecurity.io/blog/nx-console-vs-code-extension-compromised) shows exactly what “every credential in reach” means. The malware ships dedicated collectors for: - **HashiCorp Vault:** reads `~/.vault-token`, `/etc/vault/token`, `/run/secrets/VAULT_TOKEN`, and other token paths, then tries Kubernetes and AWS IAM auth endpoints - **npm:** reads `.npmrc`, validates tokens against the registry, and enumerates every package the victim can publish - **AWS:** queries instance and container metadata services, reads Web Identity tokens, and enumerates Secrets Manager and SSM Parameter Store - **GitHub:** pattern-matches `ghp_`, `gho_`, and `ghs_` tokens and scrapes CI runner process memory - **Filesystem:** regex-scans for private keys, connection strings, GCP service accounts, Docker registry auth, and Claude Code configuration in `~/.claude/` - **1Password:** drives the `op` CLI to list vaults and retrieve secrets Later waves also took AI tool configs (Codex, Cursor), Kubernetes configs, crypto wallets, and local 1Password and Bitwarden vaults. ![A backdoored npm package runs its install script in node. Santa Lockdown mode prevents the Bun binary that the script downloads from running, and Santa file access rules limit access to credential files like ~/.npmrc, ~/.kube, ~/.aws, and ~/.ssh to just the programs that need them. A package proxy, which is not part of Santa, can also hold back new package versions.](https://northpole.security/images/blog/starving-shai-hulud/santa-blocks-shai-hulud.png) *Santa Lockdown mode stops the dropped Bun binary, and file access rules keep credential files away from programs that do not need them.* ## Credential files have few legitimate readers There’s a pattern in those credentials: almost every entry is a file on disk with a tiny set of legitimate readers. Your Vault token is read by the `vault` CLI. Your `.npmrc` is read by npm. Your 1Password data belongs to 1Password. No Python script in `~/.local/share/` and no freshly downloaded Bun runtime has any business reading them. And in the May attacks, that is literally what did the reading: the Nx Console payload was an obfuscated Bun-based script with a Python backdoor for persistence. [Santa’s file access authorization rules](https://northpole.security/docs/santa/cookbook/faa) exist for exactly this type of problem. A rule names a set of paths and the processes allowed to touch them (identified by signing ID, Team ID, or certificate) and Santa’s Endpoint Security system extension blocks or logs everything else. We have examples of these in our cookbook: [Protect SSH Private Keys](https://northpole.security/cookbook/protect-ssh-keys) covers the private keys the worm’s filesystem scanner regex-hunts for, and [Protect 1Password Database](https://northpole.security/cookbook/protect-1password-database) restricts your vault data to 1Password’s own signed processes and a few required system helpers. And you can make sure the rule covers reads, not just writes, by setting `allow_read_access: false`, which is important for infostealers. ## Start in audit mode, then enforce With [Workshop](https://northpole.security/workshop), you don’t need to guess which processes deserve access on day one. Start by deploying a single audit-only rule that merely watches your fleet’s credential hot spots and let its file access events tell you who actually reads them, like this: ``` path_prefixes: - "/Users/*/.aws/" - "/Users/*/.claude/" - "/Users/*/.codex/" - "/Users/*/.cursor/" - "/Users/*/.kube/" - "/Users/*/.npmrc" - "/Users/*/.ssh/" - "/Users/*/.vault-token" options: allow_read_access: false audit_only: true rule_type: PathsWithAllowedProcesses processes: - signing_id: "platform:com.apple.mdworker_shared" ``` This rule is a starting point, not full coverage. We recommend you extend the path list with the other targets from the collector list above, like alternate Vault token paths, Docker registry auth, and GCP service account files. Let it run long enough to cover your teams’ representative workflows, including the tools that only run occasionally, and Workshop file access events will show you who legitimately reads these paths. Workshop reports an audit-only read once per rule and process every four hours, so a process that reads both `.npmrc` and `~/.aws/` may show up for only one of them. If you need the full list of readers for each path, use one audit-only rule per path. Then split the audit rule into per-path blocking rules, each naming only the signed tools that need that file, with a custom message so blocked users know who to contact. On Santa 2026.9 and later, also set the rule’s parent directory protection to enforce after you test it. Otherwise a process can rename or clone a parent folder and read the copy outside the watched path. Once Workshop sends these file access rules to your fleet, it’ll collect and log file access events so you can build, stage, and enforce this without touching a single laptop. However, file access rules aren’t perfect. Malware that runs inside a process you allowed, like a lifecycle script executing under the same `node` that legitimately reads `.npmrc`, won’t be stopped by that path’s rule. They also only govern files, so the worm’s collectors that query cloud metadata endpoints, scrape CI runner memory, or drive the `op` CLI never touch a watched path. This is why the layers matter: Santa’s [Lockdown mode](https://northpole.security/docs/santa/features/binary-authorization#client-mode) can block unapproved executables like the dropped Bun runtime from ever running, file access rules will starve whatever still executes, and telemetry helps you investigate what Santa observes. Shai-Hulud and its variants will continue to appear. Its code is public, its imitators will continue to ship, and every wave so far has counted on one assumption: that anything running on a developer’s Mac can read every secret on it. If you break that assumption, the worm goes hungry. If you want help getting there, [talk to us](https://northpole.security/contact) or check out our [cookbook](https://northpole.security/cookbook). Santa Workshop File Access Rules Supply Chain ## You may also like [ ![Closing the Tunnel: Santa and Workshop vs. the Claude Code Extension Backdoor](https://northpole.security/images/blog/closing-the-tunnel-hero.jpg) Guides • October 30, 2026 Closing the Tunnel: Santa and Workshop vs. the Claude Code Extension Backdoor A backdoored Claude Code extension on Open VSX opens a reverse SSH tunnel. Find exposed Macs, block each stage, and contain them with Santa and Workshop. ](https://northpole.security/blog/closing-the-tunnel)[ ![Blocking OpenClaw](https://northpole.security/images/blog/blocking-openclaw-hero-v2.jpg) Guides • March 6, 2026 Blocking OpenClaw OpenClaw (formerly Clawdbot and Moltbot) is an autonomous AI agent for macOS. Here's how to block every version with layered Santa CEL rules. ](https://northpole.security/blog/blocking-openclaw)[ ![Announcing Santa and Workshop 2026.9](https://northpole.security/images/blog/release-2026.9/release-2026.9-hero.jpg) Releases • October 15, 2026 Announcing Santa and Workshop 2026.9 Santa and Workshop 2026.9 add process annotations that make Lockdown livable for developers, DNS rules, security key approvals, and much more ](https://northpole.security/blog/release-20269) ## Sitemap - [Home](https://northpole.security/index.md) - [Workshop](https://northpole.security/workshop.md) - [Santa](https://northpole.security/santa.md) - [Features](https://northpole.security/features.md) - [Cookbook](https://northpole.security/cookbook.md) - [Docs](https://northpole.security/docs.md) - [Blog](https://northpole.security/blog.md) - [Glossary](https://northpole.security/glossary.md) - [About](https://northpole.security/about.md) - [Contact](https://northpole.security/contact.md)