Shai-Hulud's Reach Just Grew to 469 Credential Locations. Here's What That Means

In early August, GitGuardian researchers found 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 can 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.

This effort sits naturally between development and security. Developers understand how packages get built and released while security teams set policy and identify credential exposure across those workflows.

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 "what happens if an attacker does something malicious with stolen access?" Validity is a very useful filter here. Determining the true blast radius will help you prioritize which systems to address to eliminate long-lived secrets, or at least which to rotate secrets for.

Shared credentials create hidden paths between environments

Environment boundaries also blur when credentials get reused. A credential discovered in staging may still authenticate against production. A token copied into a developer's local environment may retain privileges meant for automation. The same credential may show up across multiple systems long after its original purpose has been forgotten.

Finding the secret is only the first step. The alerts are just noise if they do not map it back to the identity, privileges, resources, environments, and owners behind it. Multiple teams, including DevOps, platform, Identity and Access Management (IAM), and security, each hold a piece of that picture, and remediation needs to bring those pieces together.

Priority three: rank every remaining exposed secret by risk

Once package publishing and obvious production access are handled, organizations can work systematically through the remaining credential inventory. The goal isn't to rotate everything at random. It's to build an action plan that continuously removes the most useful credentials from an attacker's path.

Validity is a good place to start, but not the whole story

A valid credential deserves more immediate attention than one that's already expired or revoked. At scale, that distinction matters enormously: GitGuardian's State of Secrets Sprawl research found 28.65 million new hardcoded secrets added to public GitHub commits in 2025 alone, a 34% year-over-year increase.

Volumes at that scale make manual triage unrealistic. Organizations need to determine which findings still represent usable authentication and move those toward the front of the queue.

Validity alone still doesn't tell the whole story. A valid credential for a shared development service deserves attention. A valid credential with administrator access to a production cloud account deserves considerably more.

Useful prioritization adds context:

• Is the credential still valid?
• Does it reach production, staging, or development?
• What identity does it represent?
• What privileges does that identity have?
• Which resources can it access?
• Where else is the credential being used?
• Who owns the credential and can rotate or revoke it?

Working to make sure you have answers that can be audited turns an overwhelming list of leaked secrets into an actual remediation plan.

Credential risk reduction requires a repeatable program

This newest wave of Shai-Hulud attacks, or any variants of it, should do more than trigger a one-time credential cleanup exercise.

Credentials will likely continue to accumulate as developers keep building software, services integrate with one another, pipelines evolve, and new tools enter the environment. The response needs to become a repeatable cycle.

Organizations first need broad visibility into what they have. A single inventory of all credentials. That includes source code and Git history, but modern attacks make the case for looking further, into the CI/CD systems and developer environments where authentication material accumulates.

Detection should answer a simple question: where does reusable authority currently exist? This needs to be auditable, and not simply reflect the 'known" secrets already vaulted. The percentage of secrets that exist outside the vault is a very important metric when addressing secrets security at scale. Remediation plans without a way to account for those orphaned, plaintext secrets are doomed to fail.

Remediate according to actual risk

The next step is prioritization. As we have laid out in this post, any publishing credentials and valid production credentials belong at the top of your list. Remaining secrets need to be ranked using validity, environment, identity, privilege, ownership, and other available context. Remediation then moves through a manageable queue instead of an undifferentiated backlog.

Prevent standing credentials from rebuilding the attack path

Finally, organizations need to stop the same credential layer from rebuilding itself. That means blocking new hardcoded secrets, moving workflows toward short-lived credentials where possible, protecting credentials in developer environments, and catching new exposure before it becomes another large remediation project.

"Detection, remediation, and prevention" need to be seen as an ongoing cycle, not an emergency response triggered after an attack.

The next Shai-Hulud wave should find fewer credentials to steal

The next Shai-Hulud variant will almost certainly look somewhere new, expanding past that 469 number we started with. Attackers will keep adding paths and developer tools to their search because they have learned that modern software environments are full of reusable authority.

We are not going to win that race by memorizing every place the next infostealer might look. We win by removing standing privilege and eliminating exposed credentials everywhere they exist.

That is why the credential layer deserves to be treated as its own security problem. Detect where reusable authority exists. Remediate the credentials that create the most risk. Prevent that exposure from accumulating again.

Our goal should be to ensure that every time a new worm arrives, there are fewer findable keys to abuse.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.