Listen to this Post
Introduction
A stealthy supply‑chain worm dubbed “Mini Shai‑Hulud” has forced npm to urgently invalidate all granular access tokens that bypass two‑factor authentication (2FA). By stealing long‑lived tokens and hijacking GitHub Actions workflows, the attacker pushed over 639 malicious package versions across 323 unique packages, compromising high‑profile projects such as TanStack and Mistral AI.
Learning Objectives
- Understand how Mini Shai‑Hulud bypasses 2FA and propagates through npm ecosystems.
- Learn to audit, revoke, and replace compromised tokens using npm CLI commands.
- Implement hardened 2FA policies, Staged Publishing, and Trusted Publishing (OIDC) to block future supply‑chain attacks.
You Should Know
1. Immediate Response: Revoke All Bypass‑2FA Tokens
Step‑by‑step guide to audit and revoke risky tokens
Step 1: List all existing granular access tokens
npm token list
The output shows token IDs, creation dates, and permissions. Look for tokens marked “bypass 2FA” or “write access” that were created before 2026‑05‑19.
Step 2: Revoke each dangerous token
npm token revoke <token-id>
For example:
npm token revoke 4a2b1c3d
Step 3: Generate fresh, short‑lived tokens (without 2FA bypass)
npm token create --expires=30 --packages-and-scopes-permission=read-write
Set a short expiration (≤30 days) and never enable the `bypass-2fa` flag for CI/CD pipelines. Instead, use Trusted Publishing (OIDC) as described below.
Step 4: Rotate credentials across all environments
Delete any remaining `.npmrc` tokens and update secrets in your CI/CD providers (GitHub Actions, GitLab CI, Jenkins).
Linux/macOS – remove npm token from .npmrc sed -i '/_authToken/d' ~/.npmrc Windows (PowerShell) (Get-Content ~/.npmrc) -notmatch '_authToken' | Set-Content ~/.npmrc
2. Enforce 2FA for All Package Publishing
Step‑by‑step guide to harden 2FA settings
Step 1: Enable 2FA “authorization and writes” for your account
npm profile enable-2fa auth-and-writes
You will be prompted for an OTP from your authenticator app.
Step 2: Require 2FA for every package you maintain
npm access 2fa-required <package-name>
Example:
npm access 2fa-required @myorg/core
This forces any `npm publish` command to present a valid 2FA OTP, rendering stolen tokens useless.
Step 3: Disallow token‑based publishing entirely
Set every package to “require 2FA and disallow tokens”:
npm access set require-2fa disallow-tokens <package-name>
This blocks static‑token publishes at the registry level.
Step 4: Verify the configuration
npm access ls-collaborators <package-name>
3. Adopt Staged Publishing for CI/CD Workflows
npm’s new Staged Publishing (introduced in CLI v11.15.0) adds a review step before any automated publish reaches the registry.
Step‑by‑step guide to using Staged Publishing
Step 1: Upgrade npm CLI to v11.15.0 or later
npm install -g npm@latest
Step 2: Publish to the staging area instead of directly to the registry
npm stage publish
This command uploads your package to a private staging zone.
Step 3: Review and approve the staged release
npm stage review
You can also approve via the npm website. Only after manual (or automated with strict policy) approval does the package become publicly available.
Step 4: Automate staging in CI pipelines
In your CI configuration, replace `npm publish` with npm stage publish --no-interactive. Then set up a separate job that runs `npm stage review` after passing all quality gates.
This model prevents worms from instantly pushing malicious versions, because the attacker would need to also compromise the separate review mechanism.
- Migrate to Trusted Publishing (OIDC) – Eliminate Long‑Lived Tokens
Trusted Publishing uses OpenID Connect (OIDC) to obtain short‑lived, scoped tokens on‑the‑fly. Even if a runner is compromised, the token cannot be reused later.
Step‑by‑step guide for GitHub Actions
Step 1: Create a GitHub Actions workflow that requests an npm token via OIDC
.github/workflows/publish.yml
name: Publish to npm
on:
release:
types: [bash]
permissions:
id-token: write needed for OIDC
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
registry-url: 'https://registry.npmjs.org'
- run: npm ci
- run: npm run build
- run: npm publish --provenance
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
Step 2: Remove all static npm tokens from your repository secrets
Delete the `NPM_TOKEN` secret; the OIDC flow does not require it.
Step 3: Configure npm to accept OIDC from your GitHub repository
Visit `https://www.npmjs.com/settings/
Step 4: Verify that provenance is attached
npm audit signatures
This command checks that the published package includes a SLSA Build Level 3 provenance attestation.
5. Detect and Remediate Worm Persistence (Local Backdoors)
Mini Shai‑Hulud installs persistent hooks in IDE settings to survive reboots and re‑execute on developer machines.
Step‑by‑step guide for Linux / macOS / Windows
Step 1: Scan for the known malicious files
Linux / macOS – find router_init.js or setup.mjs in node_modules find . -name "router_init.js" -o -name "setup.mjs" -o -name "transformers.pyz" Windows PowerShell Get-ChildItem -Recurse -Include "router_init.js","setup.mjs","transformers.pyz"
Step 2: Check VS Code persistence hooks
Open `.vscode/tasks.json` and look for suspicious commands referencing `gh-token-monitor.service` or api.masscan.cloud.
Step 3: Inspect Claude Code settings
Examine `~/.claude/settings.json` for any injected scripts.
Step 4: Remove the persistence service
Linux – disable systemd service sudo systemctl disable gh-token-monitor.service sudo rm /etc/systemd/system/gh-token-monitor.service macOS – remove launch agent launchctl unload ~/Library/LaunchAgents/com.gh.tokenmonitor.plist
Step 5: Block command‑and‑control domains
Add the following to your network DNS filter:
– `filev2.getsession[.]org`
– `api.masscan[.]cloud`
– `git-tanstack[.]com`
What Undercode Say
- Token hygiene is non‑negotiable. The attack succeeded because long‑lived tokens with 2FA bypass were stored in CI/CD secret stores. Every such token should be treated as a potential backdoor and replaced with short‑lived, OIDC‑based credentials.
- Worms exploit trust, not just vulnerabilities. Mini Shai‑Hulud used valid tokens, legitimate GitHub Actions triggers, and even OIDC extraction from memory to bypass Trusted Publishing. Defense must include runtime detection (e.g., monitoring for unusual `npm publish` bursts) and not rely solely on static policies.
- Staged Publishing is a game‑changer. By separating automated builds from the final publish action, npm introduces a human‑in‑the‑loop gate that would have stopped the 639 malicious versions from ever reaching the registry. All organizations with high‑value packages should enable staging immediately.
Analysis (10 lines):
The Mini Shai‑Hulud incident is a wake‑up call for the entire JavaScript ecosystem. It demonstrates that a single stolen token can turn a trusted maintainer into an unwitting distribution point for malware. While npm’s token reset was necessary, it is only a first step. Developers must adopt a zero‑trust posture for secrets: no static tokens, mandatory 2FA for every publish, and continuous monitoring of CI/CD pipelines. The integration of Staged Publishing and OIDC‑based Trusted Publishing provides a practical path forward, but these features require active configuration—they are not on by default. Furthermore, the worm’s ability to persist inside IDE settings reveals a blind spot: endpoint security must now extend to development environments, including scanning for malicious hooks in `.vscode` and `~/.claude` directories. Organizations should also implement network‑level blocking of the IOCs listed above and rotate all potentially exposed credentials (GitHub PATs, AWS IAM keys, HashiCorp Vault tokens). Finally, training courses on “Supply Chain Security for npm” should incorporate hands‑on labs where participants simulate a token theft and practice rotating credentials under time pressure—because the next worm will not wait for a blog post.
Prediction
The Mini Shai‑Hulud attack marks the end of the era of simple, long‑lived tokens in package registries. Within the next 12 months, npm, PyPI, and RubyGems will make Trusted Publishing (OIDC) mandatory for all automated CI/CD publishes, and Staged Publishing will become the default for any package with more than 1,000 weekly downloads. Attackers will shift their focus to compromising the OIDC token‑request process itself—for example, by injecting malicious code into GitHub Actions runners that steals the OIDC token from memory before it is used. This will drive the adoption of hardware‑backed identity (e.g., TPM‑protected keys for CI runners) and real‑time anomaly detection in registry uploads. Organizations that fail to phase out static tokens by mid‑2027 will face a high probability of being the next headline.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Tushar Subhra – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
