The new Shai-Hulud worm scans 469 credential paths. The number that should worry you is 189.

Every writeup of the latest Shai-Hulud infostealer variant led with the same figure: 469 credential locations across dev environments, CI/CD tooling, and cloud configs. Almost none mentioned the earlier count, 189. That gap means the authors audited their own coverage and found 280 spots on a developer machine they had been skipping. Attackers iterate on their steal lists the way your team iterates on a roadmap.

GitGuardian's report (via The Hacker News) names categories, .env files, shell history, package-manager and CI/CD configs, CLI caches, IDE and AI tool settings, but never lists the paths. The exact enumeration matters less than you'd think. Credential files are boringly predictable. Tools write them to the same default paths on every laptop on earth.

The key line deserves a direct quote: "Attackers have stopped trying to break trust relationships and started using the credentials that already make those relationships work." A worm with 469 paths isn't exploiting anything. It reads files your account is allowed to read.

Why your laptop beats any server

~/.aws/credentials is the same path on every laptop in your fleet, so a 469-entry list covers most of it with zero reconnaissance. The worm runs as the logged-in user, so the permissions protecting /etc/shadow do nothing for dotfiles you own. And secrets cross domains: a token in a local CI config might administer a production cluster.

My arguable take: repository scanning is necessary hygiene, and it's the wrong battlefield for this worm. Shai-Hulud doesn't need you to commit anything. It reads what your tooling already cached to disk. GitGuardian counted 28.65 million new hardcoded secrets on public GitHub in 2025, and that's only what leaked into public view.

Top of the target list: package publishing. Steal a token from ~/.npmrc and you can push your code to everyone who trusts that package. Theft converts directly into distribution.

A big chunk of the new 280 paths is the AI stack. MCP server configs carry plaintext API keys for every service the agent can touch. Coding agents stash provider keys in their config directories. Fastest-growing part of the credential surface, least inventoried. Bad combination.

Audit your own machine in five minutes

Run this before you ask anyone else to. It prints which paths exist, never their contents.

paths=(
  ~/.npmrc ~/.pypirc ~/.gradle/gradle.properties ~/.cargo/credentials.toml
  ~/.aws/credentials ~/.aws/cli/cache ~/.azure ~/.config/gcloud
  ~/.kube/config ~/.docker/config.json
  ~/.git-credentials ~/.netrc ~/.config/gh/hosts.yml ~/.ssh
)
for p in "${paths[@]}"; do [ -e "$p" ] && echo "PRESENT: $p"; done

find ~ -maxdepth 4 -name '.env*' -not -path '*/node_modules/*' 2>/dev/null | head -50

Then check how git stores credentials, and scan shell history for token shapes:

git config --global credential.helper
# "store" means forge tokens sit in plaintext at ~/.git-credentials
grep -icE 'AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{20,}|npm_[A-Za-z0-9]{20,}|xox[bap]-' \
  ~/.bash_history ~/.zsh_history 2>/dev/null

Any history count above zero means a token was pasted on the command line, so it also lives in scrollback and backups. For AWS hits, aws sts get-caller-identity tells you whether the on-disk creds still work. Validity first, then rotation.

What to fix first

Publishing credentials. Long-lived npm and registry tokens are the one tier where theft becomes malware distribution through a channel your users already trust. GitHub Actions OIDC, npm trusted publishing, AWS STS for short-lived sessions: none of it costs anything. It requires deciding that a token living for a year in a dotfile is an incident that hasn't happened yet.

At fleet scale, single file reads mean nothing, since your own processes touch dotfiles all day. The tell is one non-interactive process reading dozens of these paths within seconds. Your EDR can express that query if you hand it the list above.

Do today:

• If credential.helper returns "store", your forge tokens are plaintext at ~/.git-credentials. Fix that first.
• Rotate anything the history grep finds. It also lives in scrollback and backups.
• Move publishing to trusted publishing or OIDC and retire long-lived registry tokens.
• Hand your EDR the path list. Dozens of dotfile reads by one non-interactive process in seconds is the signal.

Question for the comments: what's the oldest credential sitting in a dotfile on your machine right now, and when did you last rotate it?

Longer writeup if you want the full argument: https://axeploit.com/blog/one-laptop-469-credential-hiding-spots-what-the-new-shai-hulud-worm-is