Thought Leadership
Security researchers at GitGuardian have found that a new variant of the Shai-Hulud infostealer worm scans 469 different locations for credentials.
According to the analysis, attackers are increasingly less likely to try breaking fundamental trust relationships in the software supply chain itself—such as between developers and package registries, or between organizations and project maintainers. Instead, they specifically search for existing credentials and permissions that already underpin these trust relationships. An access token found on a developer’s machine can open up access to source code, which in turn contains cloud credentials that enable further access to infrastructure, while a GitHub token might grant write access to additional repositories. Credentials thus function as a connecting link from one compromised environment to the next.
Such credentials are no longer found only in source code repositories, but also in configuration files, shell history, CLI caches, CI/CD configurations, and development environment settings—increasingly also in the configurations of AI development tools. Package publishing credentials warrant particular attention, as their theft allows attackers to distribute malware through a channel already deemed trustworthy by other developers, turning a single theft into an independent distribution chain.
Shai-Hulud worm: Three priorities for companies to mitigate risk
As the most important immediate measure, the analysis recommends consistently removing package publishing credentials from plaintext configurations and replacing them wherever possible with short-lived, identity-bound mechanisms such as OpenID Connect—a practice recently supported more strongly by platforms like Docker and GitHub Actions.
The second priority is removing exposed credentials to actual production systems such as cloud accounts, customer databases, signing infrastructure, Kubernetes clusters, and management interfaces, as a valid access token with production access represents a significantly more severe risk than one for an isolated test environment. As a third step, the analysis recommends prioritizing all remaining exposed credentials based on actual risk, such as whether they are still valid, which environment they reach, and what permissions the associated identity possesses.
As evidence of the sheer scale of the problem, GitGuardian’s own study on the prevalence of exposed credentials points out that in 2025 alone, around 28.65 million new hardcoded secrets were added to public GitHub commits—a 34 percent increase over the previous year. Given such a volume, purely manual review is no longer practical, requiring companies to systematically evaluate which of the discovered credentials are still actually usable.
A recurring process rather than a one-time cleanup
The analysis concludes by emphasizing that responding to such worm variants must not be limited to a one-time cleanup operation, as continuous software development, new tools, and growing system integration constantly create new credentials. Instead, what is needed is a recurring lifecycle of complete inventorying of all existing credentials, risk-based prioritization of remediation, and measures that prevent the same attack surface from rebuilding through newly embedded, permanently valid credentials. The goal must be for any future worm variant to find increasingly fewer actually usable credentials during its search.
(Editorial Team)
