The Shai-Hulud Worm Now Hunts for Credentials in 469 Places — and That's a Symptom of a Tactical Shift

In early August, GitGuardian researchers spotted a new version of the Shai-Hulud infostealer worm that now hunts for credentials in 469 places — across developer environments, CI/CD tools, cloud configurations and even the settings of AI tools. Earlier variants of the worm checked only 189 paths. The growing search radius points to a shift in the logic of the attack.

Not breaking trust, but exploiting it

Software supply chains have always rested on trust: developers trust package registries, organizations trust maintainers, and CI/CD pipelines trust the tokens issued to them. The authors of Shai-Hulud realized there's no need to break that trust. It's enough to find where credentials and standing privileges already sit.

A single stolen token opens the door to source code, which often has cloud keys baked right into it; those keys grant access to infrastructure; a GitHub token lets you write to other repositories; and a package-publishing key lets you spread malware through a channel developers trust automatically. This is how secrets become the connective tissue between one compromised environment and the next, turning theft into a self-replicating attack.

Why the search radius keeps widening

A modern developer environment holds far more authentication material than the repository itself: .env files, shell history, package-manager configurations, CLI caches, IDE settings and — increasingly — AI-tool configs. The attacker doesn't need to know in advance which key matters most: they grab everything and sort it out later. Defenders, by contrast, should work backward — identify the most valuable secrets in advance and lock them down before they can be used.

What to do first

GitGuardian suggests setting priorities. First, take package-publishing keys out of the open: these are precisely what turns a stolen secret into the spread of malicious code. Long-lived publishing tokens should be replaced with short-lived mechanisms such as trusted publishing via OIDC or federated services like AWS STS; recent updates to Docker and GitHub Actions are pushing the ecosystem in that direction.

Second, eliminate accessible credentials to production: cloud accounts, databases holding customer data, signing infrastructure, Kubernetes clusters, deployment tooling. Here the key question is “what happens if an attacker uses this access,” and the filter is checking whether the key is even valid at all.

Third, rank the remaining secrets by risk, taking into account validity, environment, privileges and owner. The scale of the problem is enormous: according to the State of Secrets Sprawl research, in 2025 alone 28.65 million new hardcoded secrets landed in public commits on GitHub — 34% more than the year before.

You can't win this race by enumeration

The next Shai-Hulud variant will almost certainly peek into places it hasn't looked yet and blow past the number 469. Trying to win this race by memorizing every possible hiding spot is pointless. The winner is the one who removes standing privileges and exposed secrets everywhere they exist, turning detection, remediation and prevention into a continuous cycle. The goal is simple: to make sure each new worm finds fewer and fewer usable keys.

Source: The Hacker News