Shai-Hulud Broadens Credential Harvesting Across Developer Systems

GitGuardian researchers identified a recent Shai-Hulud infostealer worm variant that scans 469 locations for credentials across developer environments, CI/CD tooling, cloud configurations and AI-tool settings. Earlier variants checked 189 paths, a substantial expansion in the places where the malware seeks reusable access.

The change matters because the worm does not need to break every trust relationship in a software supply chain. It can use credentials that already enable those relationships, moving from a compromised workstation to source code, cloud infrastructure, build systems or package registries.

Credentials connect the attack path

A token found on a developer machine may provide access to source code, where additional cloud credentials can be present. A GitHub token may permit writes to other repositories, while a package-publishing credential may allow an attacker to publish software through a channel that downstream developers and automated builds already trust.

Authentication material is not confined to repositories. The article identifies .env files, shell history and package-manager configuration alongside CLI caches, CI/CD settings and IDE configuration. It also notes that access keys are increasingly found in configuration for AI development tools.

This breadth explains why the search radius is growing. An attacker can collect available credentials first and determine later which identities, systems and privileges each one unlocks. The location of a discovered secret alone does not establish its impact: a file on a laptop may control a cloud resource or package publication rights elsewhere.

Publishing authority deserves first priority

Package-publishing tokens can turn credential theft into propagation. They carry authority over software packages consumed by developers, organisations and build systems, creating an opportunity to distribute malicious code through a trusted publishing channel.

The immediate defensive priority is to identify where publishing tokens accumulate, including local developer configuration and pipelines, and reduce reliance on long-lived credentials. GitGuardian points to short-lived, identity-backed mechanisms such as OpenID Connect, while noting Docker and GitHub Actions updates that strengthen authentication and trusted publishing.

Credentials that cannot yet be replaced should be discoverable, validated, assigned an owner, monitored and rotated after exposure. AWS Security Token Service is another example of the shift towards federated security token services for verifying workloads across platforms.

Prioritise remediation by usable access

After publishing credentials, organisations should focus on exposed credentials that reach critical production systems, including cloud accounts, databases holding customer information, signing infrastructure, Kubernetes clusters, deployment tooling and administrative interfaces. A valid credential with write access to production infrastructure represents a different risk from one attached to an isolated development environment.

GitGuardian's State of Secrets Sprawl research found 28.65 million new hardcoded secrets added to public GitHub commits in 2025, a 34% year-over-year increase. That volume makes indiscriminate rotation impractical. Triage needs context: whether a credential remains valid, which identity it represents, its privileges, reachable resources and environments, reuse elsewhere, and the owner able to revoke or rotate it.

Teams should treat credential security as an ongoing cycle of detection, risk-based remediation and prevention rather than a one-time cleanup. For the business, the practical objective is clear: remove reusable publishing authority first, address valid production access next, and prevent new standing credentials from rebuilding the path a worm can exploit.