Mini Shai-Hulud in AntV shows how npm trust can be abused

At a glance

What this is: The AntV-focused Mini Shai-Hulud wave shows how trusted npm publishing accounts were used to push hundreds of malicious package versions and steal secrets at install time.

Why it matters: It matters because developers, CI runners, and release pipelines can execute poisoned dependencies before scanners or humans notice, forcing tighter dependency and secrets governance across software supply chains.

By the numbers:

• Socket reported 639 compromised package versions across 323 unique packages in the May 19 wave.
• 27 days

👉 Read Corgea's analysis of the Mini Shai-Hulud AntV supply chain compromise

Context

This supply chain incident is about npm trust, not just malware. When a package is published through a legitimate maintainer account, the governance problem shifts from obvious compromise to poisoned dependency resolution, where clean installs can execute hostile code before review or detection catches up. That is a software supply chain control failure with a direct secrets governance impact.

The identity angle is real because the payload targets developer and CI credentials, including GitHub tokens, npm tokens, cloud keys, and Kubernetes secrets. In practice, the compromise turns software publishing identity into an attack surface, which is why NHI controls, lifecycle review, and release-system hardening belong in the same conversation.

This pattern is not atypical for modern supply chain attacks, but the scale and speed of the publish wave make it a strong example of how fast trusted software ecosystems can be abused.

Key questions

Q: What breaks when a malicious package can run install-time scripts in CI?

A: Install-time scripts turn dependency installation into code execution, so a malicious package can steal secrets before the build is inspected. In CI, that often means cloud credentials, registry tokens, and deployment keys are exposed during routine automation. The failure mode is not just malware in source, but trust in execution timing that is too late to prevent compromise.

Q: Why do maintainer account compromises create such a large supply chain blast radius?

A: Because the maintainer identity often has publish authority, release automation access, and trust by downstream consumers. Once that identity is abused, the attacker can distribute malicious code through normal update channels and reach many environments before detection. The blast radius comes from trust amplification, not just the compromise itself.

Q: What do teams get wrong about dependency provenance and package trust?

A: Teams often assume a signed or expected package name is enough, but package metadata, lifecycle hooks, and publishing path all matter. A malicious release can keep the codebase looking normal while shifting the real risk into install-time execution. Provenance checks must therefore cover who published, how it was published, and what scripts will run.

Q: How should organisations respond when a package ecosystem attack exposes machine identities?

A: Containment should begin with revocation and rotation of machine identities, then proceed to repository, CI, and host forensics. Teams should also review publishing rights, workflow permissions, and persistence artefacts, because the initial package may have been only one part of a broader compromise path.

Technical breakdown

How install-time execution turns a dependency into an attack path

The core mechanism here is lifecycle-script execution. npm can run package scripts such as preinstall during installation, which means malicious code may execute before a human inspects the package contents. In this campaign, the tarballs included an obfuscated index.js payload and, in some cases, Git dependency paths that created a second execution route. The important technical point is that trust is resolved at install time, not at publish time, so semver ranges and dependency graphs can silently pull in poisoned versions during routine builds.

Practical implication: block or tightly control install scripts and enforce lockfile review for dependency updates in sensitive pipelines.

Why secret theft works so well in developer and CI environments

The payload was designed as a credential collector. By reading environment variables, local credential files, runner memory, and tooling artefacts, it could recover secrets that are normally considered masked or transient. That matters because CI environments often aggregate high-value access in one place, including cloud credentials, GitHub tokens, registry tokens, and deployment keys. Once those secrets are exposed, the attacker can move from package compromise to ecosystem abuse, republishing malware, harvesting more credentials, or planting persistence in developer tools and workflows.

Practical implication: treat CI and developer workstations as high-value secret hosts and reduce the number of long-lived credentials present there.

Why persistence in tooling matters after package removal

This campaign was not limited to a single malicious tarball. Reported persistence paths included .vscode/tasks.json, .claude/settings.json, GitHub Actions workflow changes, and even service-level artefacts on host systems. That changes the cleanup model: deleting the package or clearing a lockfile does not necessarily remove the foothold. In supply chain incidents, persistence in build tooling can outlast the original package version and continue to trigger credential theft or malicious republishing, especially if the attacker already obtained publish rights or tokens.

Practical implication: containment must include workstation, CI, and repo hygiene checks, not just dependency rollback.

Threat narrative

Attacker objective: The objective was to steal high-value developer and cloud credentials, then use them to sustain and expand supply chain compromise across the npm ecosystem.

1. Entry occurred through legitimate npm publish access in the compromised maintainer accounts, allowing malicious versions to be published inside trusted package namespaces.
2. Credential access happened during install-time execution, when the payload harvested GitHub, npm, cloud, and infrastructure secrets from developer and CI environments.
3. Impact followed when stolen tokens enabled republishing, persistence, and broader ecosystem spread through additional package versions and repository abuse.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Mastra npm Supply Chain Attack — Sapphire Sleet — North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.

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

NHI Mgmt Group analysis

Trusted maintainer identity is now part of the attack surface. This campaign shows that legitimate publish rights can be converted into a malware distribution mechanism without typosquatting or obvious credential theft at the outset. For identity governance, the key issue is not whether the account looked valid at publish time, but whether the publishing pathway had enough friction, verification, and blast-radius control. Practitioners should treat package maintainer identity as a privileged operational control, not a static trust label.

Install-time execution creates a secrets exposure window that scanners cannot fully close. Once a package can run code during installation, detection that arrives minutes later is already late for any developer machine or CI runner that processed the package. The governance gap is a reliance on post-publication review for threats that are executed before review completes. Practitioners need controls that reduce exposure at install time, not only after alerting.

Persistent compromise now spans developer tooling, CI, and release infrastructure. The observed use of .vscode, .claude, workflow injection, and token abuse shows how one compromised package can seed multiple footholds across the software lifecycle. This is a lifecycle governance problem, not a single-malware problem. Teams should map these incidents to OWASP Non-Human Identity Top 10 concerns and to NIST SP 800-53 controls for authenticator management and change control.

Dependency trust is becoming a named concept practitioners should govern explicitly. Dependency trust collapse describes the point at which a package ecosystem can no longer assume that namespace legitimacy, maintainer access, or provenance metadata is sufficient to guarantee safe execution. That matters for software composition, secrets hygiene, and release governance alike. The practical conclusion is clear: teams must govern dependency trust as an operational risk, not as a procurement assumption.

NHI governance must extend into build and publish systems. The stolen artifacts were not just passwords in the abstract, but machine identities, tokens, and cloud credentials that let the attacker move through tooling and publication systems. That places package pipelines squarely inside NHI governance scope. Organisations should align this problem with the OWASP Non-Human Identity Top 10 and harden privileged automation accordingly.

From our research:

• Socket reported 639 compromised package versions across 323 unique packages in the May 19 wave, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: Read 52 NHI Breaches Analysis for root-cause patterns that recur when machine identities and secrets are not governed end to end.

What this signals

Dependency trust collapse: supply chain teams should now treat maintainer identity, install-time execution, and secret-bearing build contexts as one control plane. The practical shift is toward reducing implicit trust in package installation and increasing verification around who can publish, what can execute, and where secrets exist.

Attackers are exploiting the fact that CI and developer systems still concentrate too much credential value in too few places. That means secrets scanning, dependency governance, and NHI controls need to be coordinated, not managed as separate hygiene workstreams.

The control signal to watch is not just whether a package was malicious, but whether your environment allowed the package to execute before containment. Organisations that cannot answer that question quickly will continue to overestimate their resilience.

For practitioners

• Inventory affected packages and versions across the full software estate Search package manifests, lockfiles, dependency caches, CI logs, and built artefacts for the affected AntV, utility, and maintainer-account package names. Do not rely on package.json alone, because semver ranges can resolve to malicious versions during clean installs.
• Rotate exposed credentials from a clean control point Assume compromise if an affected version ran on a workstation or CI runner, then rotate GitHub PATs, npm publish tokens, cloud keys, Kubernetes service account tokens, Vault tokens, SSH keys, and registry credentials from a known-clean environment.
• Remove persistence before declaring containment Check .vscode, .claude, .github/workflows, user systemd services, and macOS LaunchAgents for suspicious entries, then review whether any repository or workflow changes created durable execution paths beyond the package itself.
• Constrain dependency execution in untrusted contexts Apply a cooldown window for newly published npm versions, require lockfile review before CI install, and block install scripts where your build process can operate safely without them.

Key takeaways

• This campaign shows that trusted npm publishing accounts can be turned into malware delivery paths without typosquatting or obvious user error.
• The scale matters because hundreds of malicious versions can reach developer and CI environments before scanners or humans react.
• The most effective controls are install-time restraint, rapid secret rotation, and persistence checks across build and developer tooling.

Key terms

• Dependency Trust Collapse: The point at which software consumers can no longer reliably distinguish legitimate packages from malicious ones using normal trust signals. In practice, it happens when package publication, maintainer identity, and install-time execution are all assumed safe without independent verification.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Persistence artifact: A persistence artifact is any file, hook, service, or configuration that lets malware survive after the initial execution window ends. In build and developer environments, these artifacts often hide in editor settings, system services, or startup hooks and can reactivate the compromise later.

What's in the full analysis

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

• Package-by-package advisory mappings and the exact malicious version ranges for triage
• Observed payload behaviour, including credential harvesting paths and republishing logic
• Indicators of compromise for repositories, workflows, and persistence artefacts
• Remediation workflow detail for secret rotation, host cleanup, and package inventory review

👉 Corgea's full post covers the affected package inventory, payload behaviour, and remediation steps in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to connect identity governance to real operational risk across modern delivery pipelines.