Mini shai-hulud shows how CI/CD becomes an attack surface

At a glance

What this is: This is Veracode Threat Research’s analysis of Mini Shai-Hulud, npm malware that abuses CI/CD and GitHub Actions to steal secrets and spread through trusted publishing paths.

Why it matters: It matters because CI/CD credentials, workflow permissions, and maintainer trust have become identity control points, and failures there can turn software delivery into malware propagation.

By the numbers:

• 4.6% of all public GitHub repositories contain at least one hardcoded secret.
• 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent.
• 15% of commit authors have leaked at least one secret in their contribution history.

👉 Read Veracode's analysis of Mini Shai-Hulud and CI/CD secrets abuse

Context

Mini Shai-Hulud is a secrets and workflow abuse problem first, and a package-malware problem second. The key governance failure is that modern build pipelines often trust automation identities, maintainer tokens, and publishing workflows more than they should, especially when CI/CD environments can read the same secrets that release systems use.

For IAM and NHI teams, this is a concrete reminder that CI/CD runners, GitHub Actions jobs, and publishing tokens behave like non-human identities with real blast radius. When those identities are overprivileged, compromised code can move from execution to propagation without needing a classic user account takeover.

Key questions

Q: What fails when CI/CD workflows can access secrets and publishing tokens?

A: The failure is identity collapse inside the pipeline. A runner that can read secrets, write releases, and publish packages becomes a high-value non-human identity with too much authority. If that runner is compromised, attackers can steal credentials and propagate malicious code through trusted automation rather than needing separate account compromises.

Q: Why do CI/CD secrets create such a large blast radius in supply chain attacks?

A: CI/CD secrets are often shared across build, publish, and cloud tasks, so one exposed token can touch many systems at once. In this incident, the same compromise path reached GitHub, npm, AWS, GCP, Azure, Vault, SSH, and database credentials. That makes token scope and runner isolation central to blast-radius reduction.

Q: What do security teams get wrong about package provenance and trusted publishing?

A: They often assume provenance replaces older authentication paths automatically. It does not. If a legacy token, secret, or key remains valid, the attacker can use that path even when provenance controls exist. The control failure is leaving old and new trust models active at the same time.

Q: How should teams respond after a poisoned package is detected in their pipelines?

A: Contain the build environment first, then rotate any secrets that may have been present in memory, files, or tokens during install. After that, review repository branches, workflow files, and any unexpected package publication activity. The goal is to stop credential reuse and persistence before the compromise spreads into adjacent systems.

Technical breakdown

How GitHub Actions becomes a privilege bridge

GitHub Actions can become a privilege bridge when workflows run untrusted code in contexts that can still read secrets, write releases, or invoke publishing steps. The most dangerous pattern is pull_request_target, because it executes in a privileged repository context while processing external content. If workflow permissions are broader than necessary, an attacker who reaches the runner can access repository secrets, tokens, and release paths. That turns automation from a build helper into an access path.

Practical implication: review every workflow that can execute external code and strip runner permissions to the minimum required.

Why CI/CD secrets are especially easy to abuse

CI/CD secrets are attractive because they are short-lived in theory but frequently long-lived in practice, and they often authorize several downstream actions at once. A publishing token, for example, may allow package release, repository access, or access to adjacent services. If secrets are exposed inside the pipeline, an attacker does not need to escalate through multiple human accounts. The pipeline itself becomes the credential source and the trust boundary failure.

Practical implication: separate build credentials from publishing credentials and scope each token to one action only.

Trusted publishing creates a propagation channel

Trusted publishing improves release automation, but it also creates a propagation channel when the same identity that signs or publishes legitimate software can be coerced into distributing malicious updates. In supply-chain attacks, trust is not only about code provenance. It is also about who can speak for the package ecosystem at release time. Once the attacker reaches a maintainer-controlled pipeline, the malware can spread as part of routine automation rather than through user installs alone.

Practical implication: treat publishing identities as high-risk NHI assets and monitor every release event for abnormal lineage or timing.

Threat narrative

Attacker objective: The attacker wants to steal publishing and CI/CD secrets, persist inside automation workflows, and use trusted release paths to spread malicious packages at scale.

1. Entry occurs through compromised npm packages or malicious code introduced into maintainer-controlled repositories and CI/CD workflows.
2. Credential access follows when the malware harvests GitHub tokens, npm tokens, environment variables, and other secrets from privileged runners.
3. Escalation and propagation happen when the attacker abuses GitHub Actions and trusted publishing to modify workflows and push additional compromised releases.
4. Impact is the conversion of software delivery infrastructure into a malware distribution path that can spread through downstream package consumers.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD identities now need the same governance discipline as privileged human accounts. The article shows that pipeline runners, publishing tokens, and workflow permissions can be chained together into a durable attack path. That is an identity problem as much as a software-supply-chain problem, because the compromised object is a non-human identity with delegated authority. Practitioners should treat build automation as a governed identity tier, not a convenience layer.

Secrets sprawl is the control gap that makes supply-chain malware scalable. When workflows can reach environment variables, package tokens, and repository secrets from a single execution context, attackers do not need sophisticated escalation. They only need one privileged foothold. This aligns with OWASP Non-Human Identity Top 10 thinking on overprivilege and secret exposure, and it reinforces why secret scope must be narrower than the pipeline that uses it.

Trusted publishing reduces friction, but it also increases the cost of weak workflow hygiene. A release system that is easy to use is not automatically safe to trust. If maintainer workflows, branch protections, and runner isolation are not enforced, the same mechanism that accelerates delivery can accelerate compromise. For security leaders, the market signal is clear: supply-chain defense is moving toward identity-bound pipeline controls, not just code scanning.

Mini Shai-Hulud sharpens a specific named concept: pipeline identity collapse. This is the point at which build identity, release identity, and secret-bearing identity stop being meaningfully separated. The malware succeeds because those boundaries blur inside automation. Once that happens, compromise in one layer becomes release authority in the next, and practitioners need to redesign governance around identity separation, not just workflow observability.

From our research:

• 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
• 15% of commit authors have leaked at least one secret in their contribution history, according to GitGuardian.
• Start with Guide to the Secret Sprawl Challenge to map where secrets are most likely to surface across development and delivery workflows.

What this signals

Pipeline identity collapse should now be treated as a governance pattern, not an isolated incident class. When CI/CD, publishing, and secrets management blur together, the control problem shifts from detecting malware to separating authority so a compromised workflow cannot self-authorise release activity.

For identity teams, the operational question is whether build systems are managed like high-risk non-human identities. That means reviewing token scope, runner isolation, and release authority together, then mapping them to controls in the OWASP Non-Human Identity Top 10 and the MITRE ATT&CK Enterprise Matrix.

The broader signal is that software supply chain defense is converging with identity governance. The organisations that can separate build, test, and publish authority cleanly will absorb this class of malware better than those relying on secret rotation alone.

For practitioners

• Reduce GitHub Actions privilege scope Audit every workflow that can execute untrusted input, especially pull_request_target, and remove access to secrets, package publish rights, and write permissions unless a job genuinely requires them.
• Separate build and publishing identities Use distinct credentials for build, test, and release stages so that a compromised runner cannot automatically publish packages or reuse the same token across multiple environments.
• Rotate publishing tokens and audit runner exposure Rotate npm and GitHub publishing credentials after any suspicious workflow execution, and check whether runners can reach sensitive infrastructure or secret stores beyond the pipeline boundary.
• Monitor package publication lineage Track unusual release timing, version jumps, and repository provenance so that compromised automation can be detected when it attempts to publish from a maintainer-controlled path.

Key takeaways

• Mini Shai-Hulud shows that CI/CD pipelines can become malware distribution systems when non-human identities are overprivileged.
• The campaign reinforces that secrets exposure and workflow abuse are identity failures, not just software release problems.
• Practitioners should separate build, test, and publishing authority now, before compromised automation turns trusted release paths into an attack channel.

Key terms

• CI/CD Pipeline Identity: The machine identity used by continuous integration and deployment systems to authenticate to code repositories, registries, and cloud environments during automated build and deployment.
• Trusted Publishing: Trusted publishing is a release method that ties package publication to a verified CI workflow, usually with short-lived identity tokens and provenance evidence. It reduces the value of stolen legacy credentials, but only if older publish paths are fully removed and not left alongside the new flow.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.

What's in the full analysis

Veracode's full article covers the operational detail this post intentionally leaves for the source:

• Specific malicious workflow patterns, including the GitHub Actions abuse paths observed in the campaign
• The affected npm package list and the evolving indicators tied to the current investigation
• Defensive recommendations for pull_request_target usage, token scope, and runner isolation
• The malware execution detail behind Bun-based payload behaviour and propagation mechanics

👉 Veracode's full post covers the malware behaviour, workflow abuse patterns, and affected package list.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It helps security teams turn identity controls into operational practice across modern delivery environments.