Shai-Hulud's Reach Just Grew to 469 Credential Locations. Here's What That Means
A recent variant of the Shai-Hulud infostealer worm has significantly expanded its reach, now scanning for credentials across 469 locations, including developer environments, CI/CD tooling, and cloud configurations. Attackers are moving away from breaking trust relationships and instead exploiting existing credentials to propagate attacks across software supply chains. The key takeaway is that organizations need to shift their focus from simply protecting package registries to actively managing and eliminating long-lived publishing credentials and other sensitive access keys to prevent attackers from leveraging stolen credentials to spread malware and compromise systems.
In early August, GitGuardian researchers discovered that a recent Shai-Hulud infostealer worm variant had evolved to scan for credentials across 469 locations across developer environments, Continuous Integration/Continuous Deployment (CI/CD) tooling, cloud configurations, and even AI tool configs. Earlier variants of the infostealer worm only checked 189 paths. The jump says a lot. Attackers have stopped trying to break trust relationships and started using the credentials that already make those relationships work.
Software supply chains have always depended on trust. Developers trust package registries. Organizations trust maintainers. CI/CD systems trust the credentials and identities they're given. Applications trust the dependencies they pull down during a build. Attackers realized they don't need to break any of that. They just needed to find where the credentials and standing privileges already sit.
This is what is driving the current focus on software supply chain defense across multiple ecosystems. Protecting package registries and dependencies still matters, but the core of the problem, the actual required element for infostealer worms to succeed, sits underneath those systems. Attackers are hunting for reusable authority. Preventing the next Shai-Hulud starts with addressing and securing the credential layer.
Shai-Hulud turns stolen credentials into an ongoing supply chain attack. Shai-Hulud belongs to a growing class of supply chain attacks that search compromised environments for credentials they can use to continue the attack. A token found on a developer workstation might open access to source code. That same code likely contains cloud credentials, which would grant access to the infrastructure. A GitHub token might allow write access to additional repositories. A package publishing credential can let an attacker publish software through a channel developers already trust. Credentials become the connective tissue between one compromised environment and the next.
The broader ecosystem has already seen how direct that path can be. A quick scan of any security industry news site or info feed will surface a never-ending supply of stories about new infections across multiple languages, package managers, and operating systems.
Credential harvesting gives attackers somewhere to go next. Modern developer environments contain far more authentication material than the source repository alone. Credentials show up in expected places, like .env files, shell history, and package-manager configuration. But there are also secrets in CLI caches, CI/CD configurations, and IDE settings. Increasingly, teams are finding access keys in the configuration used by AI development tools.
This is why credential-harvesting malware creators keep broadening the search radius. The attacker doesn't necessarily know which credential matters most before collection begins. It can gather what's available and sort out what each credential unlocks afterward.
Defenders should work the problem in the opposite direction. Security teams must identify which credentials matter most and address their exposure before an attacker gets the chance to use them. The power to publish creates a path to propagation. Package publishing credentials deserve special attention because they turn credential theft into software distribution, forward propagating the attack. Tokens that developers use to publish carry authority over a trusted package that other developers, build systems, and organizations will automatically consume. That trust is what attackers abuse. This creates an obvious first priority for defenders: to reduce the number of standing publishing credentials available to steal.
Organizations need to cut their dependence on long-lived publishing tokens. We should encourage all software makers to adopt short-lived, verified authentication via OpenID Connect (OIDC) or similarly scoped mechanisms. Docker and GitHub Actions' recent updates have pushed the ecosystem further in this direction, including stronger authentication and greater use of trusted publishing. Any long-lived publishing credential that remains should be treated as highly sensitive infrastructure. Credentials connect systems security teams manage separately. Security teams traditionally think about their orgs in terms of security types: source control security, CI/CD security, cloud security, endpoint security, and application security. Credentials span all of these divisions and separation-of-duties requirements. A single developer can authenticate to GitHub, npm, AWS, Kubernetes, internal APIs, and build infrastructure in one normal day, and CI/CD pipelines often carry an equally diverse set. A credential left in a developer environment might represent authority somewhere completely different. The file might sit on a laptop while the credential controls a cloud resource or might grant package publication rights. Where a secret is discovered only tells part of the story. Organizations working towards secrets management maturity also need to know whether the credential is valid, what identity it belongs to, what system accepts it, what privileges it carries, which environment it reaches, and who owns its remediation. That turns secrets detection into credential risk management.
Not every exposed secret creates the same risk. A list containing 100,000 secret findings does not represent 100,000 equally urgent incidents. Some credentials are already invalid. Others reach disposable development environments. A smaller number provide access to production databases, cloud infrastructure, deployment systems, or package publication. Treating those findings identically builds queues instead of reducing risk. A useful remediation strategy starts by asking what an attacker would choose first. The answer provides a practical order of operations.
Priority one: remove package publishing keys from cleartext. This is the key action a developer and team need to pursue to stop Shai-Hulud variants and other infostealer worms. Organizations maintaining packages should identify where publishing tokens exist and determine whether standing credentials are still necessary. That search needs to extend beyond repositories.
Find publishing credentials wherever developers and pipelines leave them. Too often, package authors write authentication keys to local configuration files as part of normal workflows. But a secret doesn't need to have been committed to Git to be available to malware running on the developer machine. It's also why recent supply chain attacks increasingly target the working developer environment itself.
Security and development teams need visibility into where package publishing credentials actually accumulate, followed by a plan to remove them. Replace standing publishing credentials where possible. The hardest publishing credential for an attacker to steal is one that does not exist. But if they must exist, the shorter the window access can be granted, the better. The goal is always to eliminate reusable publishing authority sitting in cleartext. Organizations should move package publishing toward short-lived, identity-backed mechanisms wherever supported. OIDC-based trusted publishing is one example. Most cloud platforms are moving towards federated security token services like AWS STS, allowing for workload verification across platforms where you would be pushing artifacts. This area is always evolving in each package tooling ecosystem as well.
Static credentials that can't yet be replaced need tighter controls. They should be discoverable, validated, owned, monitored, and rotated when exposure occurs. Neither side can solve it alone. Priority two: remove exposed production credentials. Stopping the propagation path halts the spread of the infection but does not stop the bleeding. After publishing credentials, organizations should focus on credentials that provide access to critical production systems. This is where credential remediation becomes risk management. An exposed credential tied to an isolated development environment might create limited damage. A valid credential with write access to production infrastructure is a different incident entirely. Each organization should have its own hierarchical view of what constitutes mission critical, but a good short list might be: - Production cloud accounts - Databases containing customer information - Signing infrastructure - Kubernetes clusters - Deployment tooling - Administrative interfaces. The question to ask is