Mini Shai-Hulud hits @antv npm packages in major supply chain attack


A new Mini Shai-Hulud supply chain wave has compromised hundreds of npm package versions tied to the @antv data visualization ecosystem and related JavaScript packages.

The attack unfolded on May 19, 2026, after a compromised npm maintainer account was used to publish malicious versions of popular packages. Researchers said affected packages included @antv components, echarts-for-react, timeago.js, size-sensor, canvas-nest.js, and other related projects.

The risk is high because the injected malware targets developer machines and CI/CD environments. It steals GitHub tokens, npm tokens, cloud credentials, Kubernetes secrets, SSH keys, Vault tokens, Docker authentication files, and database connection strings.

What happened in the @antv npm attack

Socket reported 639 compromised package versions across 323 unique packages in the May 19 wave. The activity was tied to Mini Shai-Hulud, a self-spreading malware campaign that has repeatedly targeted open-source package registries.

Snyk reported that the compromised packages collectively represented about 16 million weekly downloads. That does not mean all users installed the malicious versions, but it shows how large the potential blast radius was.

The attack focused heavily on the @antv ecosystem, which developers use for charts, graphs, maps, and data visualization interfaces. The incident also affected packages outside the @antv scope, increasing the chance that unrelated applications pulled in malicious updates.

ItemDetails
CampaignMini Shai-Hulud
Main registrynpm
Main affected ecosystem@antv data visualization packages
Reported scale639 compromised versions across 323 packages, according to Socket
Key affected packageecharts-for-react, with roughly 1.1 million weekly downloads
Main riskDeveloper and CI/CD credential theft

Which packages were affected?

Researchers named several @antv packages in the affected set. These include libraries used for charts, graph visualization, geospatial rendering, analytics, and React-based interfaces.

Packages outside the @antv namespace were also affected. That widened the impact beyond one project family and raised the chance of transitive exposure through dependency chains.

Teams should not rely only on package names from public summaries. The affected-version list changed as researchers continued tracking the campaign, so developers should compare lockfiles and recent install logs against the latest vendor and security advisories.

Package or groupWhy it matters
@antv/g2Charting and visualization library.
@antv/g6Graph visualization package.
@antv/x6Diagram and graph editing package.
@antv/l7Geospatial visualization package.
@antv/s2Multidimensional data table package.
echarts-for-reactPopular React wrapper for Apache ECharts.
timeago.jsWidely used time-formatting package.
size-sensorUtility package used in layout and measurement logic.

How the malware executes

The malicious packages followed a pattern associated with Mini Shai-Hulud. The attacker injected a root-level JavaScript payload and changed package behavior so the malware could run during installation.

In many cases, the install path used a preinstall hook that launched the payload through Bun. This means the malware could execute when a developer or CI/CD pipeline installed the compromised package version.

The payload used heavy obfuscation to hide strings and logic from basic inspection. Once active, it searched the host for credentials and secrets commonly stored in developer environments.

  • GitHub tokens and repository credentials.
  • npm tokens and publishing credentials.
  • AWS keys and session tokens.
  • Kubernetes configuration and service account data.
  • HashiCorp Vault tokens.
  • SSH keys and private keys.
  • Docker authentication files.
  • Database connection strings.
  • CI/CD environment variables and secrets.

Why CI/CD systems face extra risk

Developer machines matter, but CI/CD systems can carry even more sensitive access. Build runners often hold tokens that publish packages, deploy applications, access cloud resources, and read private repositories.

The Mini Shai-Hulud payload included logic for major automation environments such as GitHub Actions, GitLab CI, Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Vercel, Netlify, and Cloudflare Pages.

If the malware ran inside a build pipeline, it could steal secrets from the environment and use them to expand the attack. That is what makes worm-like supply chain malware especially dangerous.

GitHub was used as an exfiltration channel

Researchers said the malware could use GitHub as a fallback path for stolen data. If it found a usable GitHub token, it could create repositories under the victim’s account and store harvested data in structured result files.

This tactic abuses trusted infrastructure. Security tools may allow GitHub traffic by default, so exfiltration through GitHub can blend into normal developer activity.

Socket and other researchers observed Dune-themed repository names and a reversed campaign marker connected to the attack. Defenders should search for unexpected repositories and result paths if they suspect exposure.

Indicator typeIndicator
Primary domaint[.]m-kosche[.]com
HTTPS endpointhttps://t[.]m-kosche[.]com:443/api/public/otel/v1/traces
GitHub markerniagA oG eW ereH :duluH-iahS
Decoded markerShai-Hulud: Here We Go Again
Result pathresults/results-*.json
Repository pattern<dune-word>-<dune-word>-<digits>
Payload fileindex.js

Why Sigstore abuse matters

Endor Labs reported that the campaign involved fake or misleading provenance signals through Sigstore-related behavior. That matters because developers may treat provenance badges as a sign that a package is safe.

Provenance can help confirm where a package came from, but it does not guarantee the maintainer account or build chain was clean. If an attacker controls the publishing path, a malicious package can still appear more trustworthy than it should.

Teams should combine provenance checks with package behavior analysis, lockfile review, maintainer account monitoring, and install-script controls.

What developers should do now

Developers should audit any project that installed or updated affected packages on May 19, 2026. The safest response is to assume secrets exposed to affected installs may have been stolen.

Teams should review package lockfiles, CI/CD logs, npm install output, and network telemetry. They should also check whether new GitHub repositories appeared under developer or automation accounts.

Credential rotation should happen from clean systems. Rotating secrets from a machine that still contains the malware can expose the new credentials as well.

  1. Check all projects for recent installs of affected @antv and related packages.
  2. Compare lockfiles against published affected-version lists.
  3. Revert to known-clean package versions where needed.
  4. Remove malicious package versions from local caches and build environments.
  5. Rotate GitHub, npm, AWS, Vault, Kubernetes, Docker, SSH, and database credentials.
  6. Review GitHub accounts for unexpected Dune-themed repositories.
  7. Search CI/CD logs for unexpected preinstall scripts and Bun execution.
  8. Block or alert on traffic to known malicious endpoints.

What organizations should change

This attack shows why automatic dependency updates can create risk when a trusted package maintainer account gets compromised. A normal-looking version update can become a credential theft path within minutes.

Organizations should restrict install scripts in CI where possible, require lockfile review for critical projects, and avoid giving build jobs broad long-lived credentials.

They should also move toward short-lived tokens, least-privilege CI permissions, protected npm publishing flows, and stronger monitoring for unusual package publication activity.

  • Use dependency pinning and lockfiles for production builds.
  • Disable lifecycle scripts in CI unless a project explicitly needs them.
  • Use short-lived credentials for cloud and package registry access.
  • Limit npm publish rights to dedicated protected accounts.
  • Require multi-factor authentication for package maintainers.
  • Monitor for sudden version bursts from trusted packages.
  • Review third-party packages before allowing automatic updates.

Mini Shai-Hulud keeps targeting developer trust

The @antv wave shows how Mini Shai-Hulud continues to target the trust chain behind modern software development. The attack did not need to trick end users directly. It abused package publishing, install scripts, CI/CD secrets, and developer workflows.

GitHub search reveals a rapidly updating cluster of threat actor-created repositories

That makes the incident larger than one compromised namespace. Any organization that installed affected package versions should treat the event as a potential credential exposure incident.

The immediate priorities are clear: identify affected installs, rotate secrets from clean systems, inspect GitHub and CI/CD activity, and tighten controls around package updates and install-time scripts.

FAQ

What happened to the @antv npm packages?

Attackers used a compromised npm maintainer account to publish malicious versions of @antv and related packages as part of a Mini Shai-Hulud supply chain wave on May 19, 2026.

How many packages were affected in the Mini Shai-Hulud @antv wave?

Socket reported 639 compromised package versions across 323 unique packages. Other researchers reported slightly different totals as their trackers updated during the incident.

What data did the malicious npm packages try to steal?

The malware targeted GitHub tokens, npm tokens, AWS credentials, Kubernetes secrets, Vault tokens, SSH keys, Docker authentication files, database connection strings, and CI/CD secrets.

Why was GitHub involved in the exfiltration chain?

If the malware found a usable GitHub token, it could create repositories under the victim’s account and commit stolen data into result files. This abused trusted GitHub traffic as a fallback exfiltration channel.

What should developers do after the @antv npm compromise?

Developers should audit recent dependency installs, compare lockfiles against affected-version lists, revert to known-clean versions, rotate exposed credentials from clean systems, and review GitHub and CI/CD logs for suspicious activity.

Readers help support VPNCentral. We may get a commission if you buy through our links. Tooltip Icon

Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more

User forum

0 messages