Mini Shai-Hulud attack hits @antv npm packages and puts CI/CD secrets at risk

A new Mini Shai-Hulud supply chain attack compromised the @antv npm ecosystem and pushed malicious package versions into developer pipelines. The campaign targeted CI/CD environments, with a payload built to steal credentials from GitHub Actions, cloud platforms, npm, Kubernetes, HashiCorp Vault, and 1Password.

Microsoft said the attack began with a compromised @antv maintainer account. The attacker then published malicious versions of widely used data visualization packages, causing the compromise to spread into downstream libraries such as echarts-for-react.

The risk is serious because the malicious code ran during npm install. Developers did not need to open a suspicious file or run a separate command. A poisoned dependency was enough to start the credential-theft chain in affected build environments.

How the @antv npm attack spread

The @antv ecosystem powers charting, graph visualization, mapping, and dashboard features used across many applications. Once the maintainer account was compromised, the attacker gained the ability to publish malicious package versions that looked like normal dependency updates.

Snyk said the campaign published 637 malicious versions across 323 packages during a fast automated burst on May 19, 2026. The security firm estimated the affected packages represented about 16 million weekly downloads, showing how quickly one compromised publishing account can affect a large developer ecosystem.

The attack also reached packages outside the @antv scope. Security researchers linked the campaign to packages such as echarts-for-react, size-sensor, timeago.js, and testing utilities, increasing the chance that organizations pulled the malware through normal dependency chains.

Detail	What researchers reported
Campaign	Mini Shai-Hulud
Main ecosystem affected	@antv npm packages and related downstream libraries
Attack method	Compromised npm maintainer account and malicious package publishing
Execution trigger	npm install through a package lifecycle hook
Main target	CI/CD credentials and cloud secrets
GitHub response reported by Microsoft	640 malicious packages removed and 61,274 npm tokens invalidated

What the malware tried to steal

The malicious payload was a heavily obfuscated JavaScript file of about 499 KB. It executed during installation and focused on Linux-based GitHub Actions environments, where build systems often have access to secrets needed for deployment, package publishing, and cloud access.

According to the Microsoft Security Blog, the payload targeted GitHub tokens, AWS credentials, HashiCorp Vault tokens, npm tokens, Kubernetes service account tokens, and 1Password data. It also tried to scrape secrets directly from GitHub Actions runner memory, which can bypass normal secret masking in logs.

That behavior makes the incident more dangerous than a typical malicious package that steals local files. The malware aimed at the systems developers use to build, publish, and deploy software. If successful, it could give attackers the access needed to poison more packages, alter repositories, or reach cloud environments.

Fake provenance made the attack harder to trust-check

One of the most worrying parts of the campaign was its use of software supply chain trust signals. Researchers said the attackers attempted to make malicious packages look legitimate by abusing or forging provenance-related signals.

Endor Labs reported that malicious packages in this wave could show valid-looking Sigstore-related badges, even though the build chain behind them belonged to the attacker. That matters because many developers and security tools increasingly rely on provenance data to judge whether a package came from a trusted workflow.

The campaign also used dormant or older packages as part of its spread. Packages with long gaps between releases may attract less immediate attention when a new version appears, especially if dependency updates run automatically.

GitHub and security teams moved to limit the damage

Microsoft said GitHub removed 640 malicious packages and invalidated 61,274 npm granular access tokens with write permissions and 2FA bypass. GitHub also pushed advisories through the GitHub Advisory Database and alerted developers through Dependabot and npm audit.

StepSecurity reported that stolen CI/CD secrets were being pushed into public GitHub repositories as part of the campaign’s exfiltration pattern. The firm said more than 2,200 public repositories had been observed with naming and description patterns tied to the Shai-Hulud activity.

The rapid response helped reduce further abuse, but it does not automatically clean affected developer machines or CI/CD runners. Any organization that installed affected versions during the exposure window should treat secrets available to those environments as exposed.

What developers should check now

Developers and security teams should start by checking whether affected @antv packages or related downstream packages were installed during the May 19 exposure window. This includes direct dependencies and transitive dependencies pulled in through other libraries.

• Review package-lock.json, yarn.lock, pnpm-lock.yaml, and CI build logs for affected versions.
• Run npm install or npm ci with –ignore-scripts while investigating suspicious dependency activity.
• Rotate GitHub tokens, npm tokens, CI/CD secrets, cloud keys, and deployment credentials exposed to affected runners.
• Audit GitHub accounts for unexpected repositories, commits, workflows, or branches created during the incident window.
• Pin known-good dependency versions until the affected packages and mirrors have been cleaned.

The Snyk report recommends pinning packages to clean versions, using –ignore-scripts during installation where possible, and rotating all credentials from affected environments. Those steps matter because stolen tokens can outlive the malicious package versions that exposed them.

Why this attack matters for open-source security

Mini Shai-Hulud shows how modern supply chain attacks now target the development pipeline itself. Instead of focusing only on end users, attackers went after maintainers, package registries, CI/CD runners, and trust systems that software teams depend on every day.

The Endor Labs timeline also shows how quickly the campaign moved, with initial detections beginning around 01:39 UTC and additional malicious versions appearing within minutes. This gives defenders very little time to react when automated publishing and automatic dependency updates combine.

The StepSecurity analysis adds another important point: the attack did not stop at stealing credentials. It used stolen access to create more infrastructure and expand the blast radius, which makes post-incident auditing just as important as package cleanup.

The incident will likely push more teams to review dependency update policies, lockfile controls, maintainer account protections, package provenance checks, and CI/CD secret handling. For now, the safest assumption is simple: if a vulnerable package ran in a privileged build environment, rotate the secrets and investigate the runner.

FAQ