Shai-Hulud in the Wild: What Security and Incident Response Teams Need to Know

Software supply chain attacks are moving beyond malicious packages.

The evolution of Shai-Hulud demonstrates a broader and more consequential shift: attackers are increasingly targeting the trusted systems used to build, publish, and distribute software. A compromised dependency may be the entry point, but the real exposure can extend across developer workstations, CI/CD pipelines, source code repositories, cloud environments, credentials, and downstream customers.

For security and incident response teams, this changes the central question. It is no longer simply, “Did we install a compromised package?”

Teams need to determine whether malicious code executed, what it could access, which trust boundaries it crossed, and whether the organization can safely rebuild and resume operations.

Based on Sygnia’s frontline experience responding to Shai-Hulud incidents, here is what organizations need to understand about the campaign, the challenges it creates during incident response, and the steps security teams can take to reduce the impact of the next software supply chain attack.

On-Demand Webinar

Shai-Hulud in the Wild:
What Security and IR Teams
Need to Know

Watch the Replay

What is Shai-Hulud?

Shai-Hulud is a self-propagating software supply chain malware campaign that compromises trusted software and development workflows to steal credentials and spread to additional environments.

The campaign initially emerged in September 2025 and has continued to evolve. More recent activity illustrates how the attack model has expanded beyond compromising individual NPM packages toward targeting the infrastructure and trust mechanisms surrounding software development and distribution.

That distinction matters.

A malicious package creates risk for organizations that consume it. But when attackers compromise the identities, workflows, and release infrastructure responsible for distributing trusted software, they can potentially use legitimate mechanisms to propagate malicious code downstream.

In other words, the target is no longer only the package. It is the trust around the package.

How does a Shai-Hulud supply chain attack work?

While individual variants differ, Sygnia has observed a recurring attack pattern.

1. Compromise an upstream maintainer

The attack typically begins by compromising a maintainer of widely used software, often through phishing or by exploiting vulnerabilities in the maintainer’s environment or release workflows.

Once access is established, attackers can use the maintainer’s legitimate privileges to poison software releases.

2. Distribute malicious code through trusted channels

The compromised maintainer’s legitimate pipeline becomes the distribution mechanism.

Malicious code may be introduced into NPM packages, GitHub Actions, or other software releases. Downstream developers and CI workloads then consume what appears to be a legitimate release.

Pre- or post-install scripts can subsequently execute the malware automatically.

3. Harvest credentials and secrets

Once executed on a developer workstation or CI runner, the malware begins searching for credentials available to that workload.

Depending on the environment, exposed secrets may include:

• Developer credentials
• NPM publishing keys
• GitHub and GitLab tokens
• CI/CD secrets
• Cloud credentials
• Kubernetes credentials
• Vault credentials
• SSH keys
• SAS keys

The malware can also leverage techniques commonly used by legitimate security tools to locate secrets embedded within source code and development environments.

4. Exfiltrate credentials

After collecting credentials, the malware establishes a command-and-control mechanism to exfiltrate them.

The mechanisms have evolved between variants. In activity discussed during the webinar, Sygnia observed the use of a smart contract and blockchain infrastructure as part of the exfiltration mechanism, making traditional domain-based blocking less effective.

5. Establish persistence and expand access

Some variants also establish persistence, including through processes on developer workstations or by registering additional self-hosted runners.

More importantly, stolen credentials can give attackers access to publishing systems and other environments. Publishing credentials, for example, can enable an attacker to release another infected version of software, creating another wave of downstream victims.

This self-propagating model is what makes the attack particularly challenging to contain.

Why are secrets so important in Shai-Hulud incidents?

In traditional incident response, lateral movement often involves an attacker moving between hosts.

In Shai-Hulud incidents, credentials and secrets can effectively become the lateral movement path.

A compromised CI runner may have access to source repositories, cloud services, deployment systems, key vaults, and production environments. If the malware collects credentials associated with those systems, the incident can move beyond the original workload without requiring traditional network-based lateral movement.

That means a seemingly isolated software dependency issue can quickly become a broader identity, cloud, development, and business-continuity problem.

The critical investigation question becomes ‘What else can this access reach?’

Sygnia uses this question to help identify critical attack paths and prioritize controls capable of removing attacker access rather than treating every exposed credential as equally urgent.

Why is responding to Shai-Hulud so difficult?

There are five challenges to supply chain incidents:

1. Secret exposure can happen at scale

Security teams may suddenly face hundreds or thousands of potentially exposed secrets without immediately knowing which remain valid, where they are used, who owns them, or what business systems they can access.

2. Trying to rotate everything simultaneously is rarely practical.

Organizations also frequently lack a centralized source of truth for credential remediation. During an incident, different teams may rotate the same credential multiple times while another credential is missed entirely.

There is another important distinction: rotation and revocation are not necessarily the same action.

For certain credentials, rotating a secret without revoking the previous value may leave the old credential usable. Incident response teams therefore need a controlled process for identifying, revoking, rotating, validating, and tracking exposed credentials.

3. The compromised environment may contain critical evidence

Moving quickly to remove credentials is important, but investigation teams also need evidence to understand whether exposed credentials were, in fact, abused.

Preserving information about compromised credentials can help investigators search historical activity and determine whether the attacker used them to re-enter other parts of the environment. Without that evidence, remediation can inadvertently make scoping more difficult.

4. Your own software can reinfect you

Supply chain incidents introduce an unusual recovery challenge: the systems being used to recover may themselves be part of the compromised trust chain.

Sygnia has encountered incidents in which an affected organization not only published compromised software downstream but also consumed its own packages internally. As a result, restoring one portion of the development environment could potentially trigger infection elsewhere.

Effective recovery may therefore require teams to pause, purge, and rebuild pipelines from trusted resources rather than simply removing the initial malicious package.

5. The technical incident can quickly become a business crisis

When compromised packages have already reached customers or downstream consumers, the incident may become public before responders fully understand its scope.

Executives, customers, legal teams, media, partners, and security researchers may all require answers while technical teams are still investigating.

At that point, incident response is no longer exclusively a technical exercise. It becomes a broader crisis-management challenge requiring technical investigation, business decision-making, and communications to operate in parallel.

How should organizations respond to a Shai-Hulud incident?

Sygnia’s experience responding to these incidents points to three priorities:

1. Automate high-volume response tasks

At scale, manual credential validation and remediation quickly become operationally unsustainable.

Sygnia has built tooling around recurring response tasks such as validating secrets, determining ownership, prioritizing exposure, mapping attack paths, and tracking credential rotation.

The objective is not automation for its own sake. It is to remove repetitive work so responders can focus their time on investigative and business decisions.

2. Assume exposure extends beyond the first finding

Finding the malicious package, or even removing it, is not the same as establishing the full scope of the compromise.

If a credential was exposed, responders should treat it as potentially usable. If one part of the development environment was compromised, teams should examine the architecture around it and determine what additional systems that access could reach.

Prioritize credentials based on impact.

When thousands of secrets may be involved, organizations cannot realistically treat them all with equal urgency.

Prioritization should focus first on credentials that provide access to the most critical systems or create the most significant paths for attacker re-entry.

3. Recover from trusted infrastructure

Recovery requires confidence that the environment used to build and distribute software can once again be trusted.

That may mean freezing affected pipelines, rebuilding compromised runners, removing persistence, validating credentials, and restoring development infrastructure from known-good sources.

Ultimately, the objective is not simply to remove malware. It is to restore confidence that the organization is once again building, publishing, and delivering trusted software.

How can organizations prepare for the next software supply chain attack?

The specific package, vulnerability, or exfiltration mechanism used in the next campaign cannot be predicted. Organizations can, however, make their development environments significantly harder to exploit and easier to recover.

Based on Sygnia’s incident response experience, several controls deserve particular attention.

Know your CI/CD secrets before an incident

Organizations should understand what credentials exist in CI/CD environments, where they are stored, who owns them, what permissions they provide, and how they can be revoked and rotated.

Building this inventory during an active incident is considerably more difficult than maintaining it beforehand.

Reduce the blast radius of individual workflows

Secrets should be segregated wherever possible so that compromising one workflow does not automatically expose the entire build or delivery environment.

The goal is straightforward: one compromised workflow should not equal one compromised development ecosystem.

Treat CI/CD runners as untrusted execution environments

Runners execute code that may originate outside the organization. Even trusted dependencies can change, and maintainers themselves can be compromised.

Organizations should therefore design runner environments under the assumption that malicious code could eventually execute within them.

That means restricting network access, limiting connectivity to production environments, controlling internet egress, and collecting sufficient telemetry to investigate activity if something goes wrong.

Pin dependencies to immutable references

Mutable version tags can be redirected to malicious releases after a maintainer or release workflow is compromised.

Where practical, organizations should pin dependencies to immutable references, such as a reviewed and trusted commit SHA, so a newly published malicious version cannot automatically execute simply because a tag has changed.

Build the ability to freeze critical pipelines

During an active supply chain incident, continuing to build and distribute software can perpetuate the compromise.

Organizations should identify critical pipelines in advance, understand the operational consequences of pausing them, and develop a playbook for safely freezing, rebuilding, and restoring them.

That capability can help stop malicious artifacts from continuing downstream while giving responders the space required to re-establish trust.

What should security leaders ask their teams now?

Shai-Hulud provides an opportunity to evaluate software supply chain readiness before the next incident.

Security leaders should be able to answer:

• Do we know which secrets are accessible from our critical CI/CD workflows?
  
• Can we identify the owner, purpose, permissions, and business impact of those credentials?
  
• Can exposed credentials be revoked and rotated quickly and in a coordinated way?
  
• Are CI/CD runners sufficiently segmented from production and other critical infrastructure?
  
• Do we collect enough telemetry from runners to reconstruct an incident?
  
• Are critical dependencies pinned to immutable, reviewed versions where appropriate?
  
• Can we quickly determine whether a compromised dependency actually executed?
  
• Can we identify what systems that execution environment could reach?
  
• Do we know how to pause our most critical pipelines without creating uncontrolled business disruption?
  
• Can we rebuild compromised development infrastructure from trusted resources?
  
• Do security, engineering, legal, communications, and executive teams know how they will coordinate if a supply chain compromise becomes public?

These questions move the conversation beyond vulnerability management and toward operational resilience of the software delivery ecosystem itself.

The bigger lesson from Shai-Hulud: protect the trust chain

Shai-Hulud should not be viewed solely as an NPM malware problem.

Its evolution illustrates how software supply chain attacks can move progressively closer to the infrastructure organizations rely on to create and distribute trusted software. Developer environments, CI/CD systems, automation identities, credentials, release mechanisms, and downstream consumers can all become part of the attack surface.

That requires a corresponding shift in defense.

Organizations cannot predict which dependency will be compromised next. They can build environments where executing one malicious dependency does not automatically expose every credential, unlock production infrastructure, or undermine the integrity of the entire delivery process.

And when prevention fails, readiness matters just as much: knowing what executed, understanding what it could reach, rapidly closing attacker pathways, rebuilding from trusted infrastructure, and returning the business to safe operations.

Want to go deeper into how Shai-Hulud works and what these incidents look like in real environments?

Watch Sygnia’s “Shai-Hulud in the Wild: What Security and IR Teams Need to Know” webinar for insights from Sygnia experts who have responded to Shai-Hulud incidents firsthand. The session explores the campaign’s evolution, how the malware propagates, the challenges responders encounter during live incidents, and practical steps organizations can take to strengthen their CI/CD environments against the next supply chain campaign.