The Google Chrome team, along with the Microsoft Edge team, published a SKILL.md file as part of their Modern Web Guidance project. It is a structured instruction set you drop into your AI coding agent so it knows how to implement browser security correctly instead of improvising. Project is in early preview. Link in comments.

---

When you ask your agent to "add authentication" or "set up cookies" or "make the login form work," it does something. It just does not always do the right thing by default. Not because it is broken, but because secure defaults require knowing the threat model, and your agent was not given one.

This skill file gives it one.

The skill is structured in three phases. Phase 1 is immediate fixes that cost nothing: stop using innerHTML with user input, set SameSite, HttpOnly, and Secure on every cookie, add X-Frame-Options: SAMEORIGIN to block clickjacking, and configure HSTS correctly. The skill is specific about starting HSTS with a short max-age and increasing it over time. Misconfiguring it with a long value on day one can lock users out of your site until that duration expires in every browser that saw it.

Phase 2 is observation before enforcement. Deploy Content Security Policy in report-only mode first. Violations get logged, nothing gets blocked. You find out what your app is actually doing before you restrict anything. Skipping this step is how you end up with a CSP that breaks your own scripts in production.

Phase 3 is enforcement with data: CSP, cross-origin isolation, Trusted Types. Trusted Types blocks string injection into dangerous DOM sinks at the browser level, which is a structural fix rather than a "hope the code is careful" fix.

To install:

npx modern-web-guidance@latest install

It runs a wizard that detects your agent and places the skill file in the right location. For Claude Code that is CLAUDE.md, for Cursor it is .cursorrules, for GitHub Copilot CLI there is a plugin flow.

One caveat worth stating clearly: this covers browser-side defenses only. Server-side authorization, SQL injection, rate limiting, and secrets management are outside its scope. It is not a complete security solution. It is the browser layer, done correctly, which is consistently wrong in AI-generated code by default.

If you are using React or Next.js, there are some framework-specific gotchas worth knowing about. Posting those and the github link in the comments.

This is a follow-up to yesterday's beginner level post. This is an involved intermediate to advanced level audit.

How the attack actually works?

You tell your AI agent "add this package." The agent runs `npm install`. Before a single line of your code even runs, the infected package fires a hidden script — a preinstall hook that executes automatically, silently, the moment npm touches it. That script steals everything in your environment: GitHub tokens, npm publish tokens, AWS keys, whatever is in your .env files or shell session. It then uses those credentials to inject itself into other packages you maintain and republishes them. That is how 172 packages got hit in 48 hours.

The part that should genuinely worry you: these packages had valid signatures and valid provenance attestations. They looked clean to every automated check. Teams that were following all the right practices still got hit.

AI coding agents are the perfect vector for this because they install packages fast and without asking. The worm is not a coincidence — it is specifically designed for that workflow.

Finding out if you are infected

Run all four. If anything returns output, go straight to the next section.

1. Look for the worm's payload files in node_modules:

   find node_modules -name "router_init.js" -o -name "router_runtime.js" -o -name "setup.mjs" -o -name "execution.js" -o -name "transformers.pyz"

2. Check if the worm is running as a daemon right now:

   pgrep -la gh-token-monitor

If this returns anything, stop. Do not revoke tokens yet. Killing the daemon comes first — skipping this step triggers a wiper that will destroy credentials before you finish rotating them. The order matters.

3. Check for the worm's marker string in your project and agent configs:

   grep -r "Mini Shai-Hulud"
   ~/projects
   ~/code
   ~/dev
   ~/.vscode
   ~/.claude
   ~/.config
   /tmp
   2>/dev/null

Adjust the project paths to wherever you actually keep your repos — ~/projects, ~/code, ~/work, whatever your layout is. The point is to cover every directory where your agent has been active, not just the current working directory. Also worth running from your home directory if you are not sure:

grep -r "Mini Shai-Hulud" ~/ --include="*.js" --include="*.json" --include="*.mjs" 2>/dev/null

The --include flags keep it from hanging on binary files or node_modules inside every project. TeamPCP commits this string to every repo the payload reaches. Think of it as a calling card you really do not want to find.

4. Check for scripts you did not write in package.json:

   cat package.json | grep -A5 '"scripts"'

Any preinstall, postinstall, or prepare entry you do not recognise is a problem. This is how the worm persists through reinstalls.

Fixing it

Do these in order. Sequence is not optional here.

1. Kill the daemon before you touch any tokens

pkill -f gh-token-monitor

macOS: launchctl remove gh-token-monitor
Linux: systemctl stop gh-token-monitor

2. Clean worm files from your agent config directories

ls -la ~/.claude/
ls -la ~/.vscode/

Manually delete anything named `router_runtime.js`, `setup.mjs`, or any .js file you did not put there. Also open `.vscode/settings.json` and remove any entries under `terminal.integrated.env` or tasks that point to scripts outside your project.

3. Rotate every credential that was on that machine

In this order — npm and GitHub first because the worm uses them to keep spreading:

1. npm publish tokens — npmjs.com/settings/tokens
2. GitHub Personal Access Tokens — github.com/settings/tokens
3. GitHub Actions OIDC publish grants — revoke them, then re-scope to a specific protected branch before re-enabling
4. AWS access keys
5. HashiCorp Vault tokens
6. Kubernetes service account tokens
7. Every secret in every .env file in that environment

If it was on that machine or in that CI runner, consider it gone.

4. Reinstall clean

rm -rf node_modules package-lock.json
npm install
npm audit

Do not move forward if npm audit shows HIGH or CRITICAL. That is not a suggestion.

Stopping it from happening again

Pin your versions. Every ^ and ~ in your package.json is an open door.

"axios": "^1.6.0"   <-- this is wrong
"axios": "1.7.9"    <-- this is right

Remove all fuzzy ranges. Commit your package-lock.json. If it is in your .gitignore, take it out.

Add this to your agent system prompt — works in Cursor, Claude Code, Copilot, Windsurf:

Before running npm install or adding any package:
1. Show me the exact package name and version. Wait for my approval before proceeding.
2. Check if that package version has any known CVEs. Run: npm view <package>@<version> --json | grep -A5 scripts
3. Flag any preinstall, postinstall, or prepare scripts and tell me what they do.
4. After installing, scan node_modules for: router_init.js, setup.mjs, router_runtime.js, execution.js
5. Run npm audit. Stop and report if anything is HIGH or CRITICAL.
Do not install packages automatically.

Add .npmrc to your project root:

ignore-scripts=true
ci=true

ignore-scripts=true blocks lifecycle hooks from running on install.

>Note: some packages with native bindings need this turned off — test first and whitelist consciously rather than disabling blindly.

Set a minimum release age. I din't know npm has this option. This one is underused and directly counters the fast-publish attack window — Mini Shai-Hulud published 403 malicious versions in under six hours. If your package manager refuses to install anything published in the last 24–72 hours, that entire window closes. Your package manager's config enforces this, not your agent's goodwill.

Package manager	Where	Setting	Unit	Min version
npm	.npmrc	min-release-age=X	days	v11.10.0
pnpm	pnpm-workspace.yaml	minimumReleaseAge: X	minutes (default 1440 from v11)	v10.16.0
Yarn	.yarnrc.yml	npmMinimalAgeGate: X	ms/s/m/h/d/w, e.g. 7d (bare number = minutes)	v4.11
Deno	deno.json	"minimumDependencyAge": "X"	minutes, ISO-8601 duration, or RFC3339 timestamp	v2.6.0
Bun	bunfig.toml	[install] block → minimumReleaseAge = X	seconds	v1.3.0

Quick examples for 3 days:

# .npmrc (npm v11.10.0+)
min-release-age=3

# pnpm-workspace.yaml (pnpm v10.16.0+)
minimumReleaseAge: 4320

# .yarnrc.yml (Yarn v4.11+)
npmMinimalAgeGate: 3d

// deno.json (Deno v2.6.0+)
{
  "minimumDependencyAge": "P3D"
}

# bunfig.toml (Bun v1.3.0+)
[install]
minimumReleaseAge = 259200

24 hours catches most fast-publish attacks. 72 hours gives the community more time to flag something before it lands in your project. Going beyond a week will start annoying your team when they genuinely need a new release quickly — pick your tradeoff consciously.

Checklist

• [ ] Four detection commands run, nothing found
• [ ] No gh-token-monitor process running
• [ ] ~/.claude/ and ~/.vscode/ directories checked and clean
• [ ] All credentials rotated in the right order
• [ ] No ^ or ~ left in package.json
• [ ] package-lock.json committed to git
• [ ] Agent system prompt updated
• [ ] Minimum release age configured for your package manager
• [ ] npm audit returns zero HIGH or CRITICAL

If you have any suggestion to secure against these kinds of attacks, please comment and tag me. I will add to this post.

Note: Dependency pinning is not a full blown solution because transitive deps are not pinned but is still a recommended practice. Run `npm audit` as part of your deployment process and review them critically.

TL;DR: mini-shai-hulud is actively spreading through unpinned npm packages. If your package.json uses fuzzy version ranges like ^, ~, or *, your AI agent may have silently installed a compromised version during a routine npm install. Check and fix your deps today.

---

🪱 What is mini-shai-hulud?

Named after the great sandworms of Dune, mini-shai-hulud is a worm that burrows through the npm ecosystem by hijacking packages with loose version constraints. It exploits the fact that vibe-coding sessions and AI agents often run npm install automatically, without a human reviewing exactly what version gets pulled.

It can:

• Exfiltrate environment variables and API keys
• Inject malicious code into your build output
• Spread itself into packages your project publishes

---

🛡️ Step 1: Pin every dependency in package.json

Stop using fuzzy ranges. Change this:

"dependencies": {
  "axios": "^1.6.0",
  "lodash": "~4.17.0"
}

To exact pinned versions:

"dependencies": {
  "axios": "1.6.8",
  "lodash": "4.17.21"
}

Also commit your package-lock.json to version control. Never .gitignore it.

---

🛡️ Step 2: Ask your AI agent to audit before installing

Add this to your agent system prompt or first message in every coding session:

> "Before running npm install or adding any package, check the exact version for known CVEs using npm audit. Only install if the version is clean. Pin the exact version in package.json."

---

🛡️ Step Run npm audit right now

npm audit

If you see HIGH or CRITICAL vulnerabilities, do not ignore them.

To auto-fix safe upgrades:

npm audit fix

⚠️ Do NOT blindly run npm audit fix --force it can downgrade major versions and break your app.

---

🛡️ Step 4: Upgrade transitive (nested) dependencies WITHOUT breaking your top-level packages

This is the tricky part. Sometimes the vulnerable package isn't one you installed directly, it's a dependency of a dependency.

Option A: Use npm overrides (npm v8.3+)

In package.json, force a specific version of a transitive dep:

"overrides": {
  "vulnerable-transitive-package": "2.1.4"
}

Then run npm install. This pins the nested dep without touching your top-level packages.

Option B: Use npx npm-force-resolutions (for older npm)

npx npm-force-resolutions
npm install

Option C: Check what's pulling the bad package

npm why vulnerable-package-name

This shows the full dependency chain. If the parent package has a patched version available, upgrade only that parent:

npm install parent-package@latest

Verify nothing broke:

npm audit

---

📋 Checklist for vibe-coders and agent users

• All deps in package.json use exact versions (no ^ or ~)
• package-lock.json is committed to git
• npm audit returns 0 HIGH/CRITICAL issues
• AI agent has instructions to audit before installing
• overrides used to patch any vulnerable transitive deps
• .env files are in .gitignore

---

Stay safe out there. The sandworm is patient. Your dependencies are not. Share this to other vibe-coders too.