In the fast-paced world of open-source software development, maintaining the integrity of our software supply chains has become one of the most critical and complex challenges for DevSecOps professionals and security engineers. As of 2026, we are witnessing a severe escalation in the sophistication of malicious campaigns targeting the npm ecosystem. The latest, and perhaps most alarming of these incidents, is the Mini Shai-Hulud attack targeting the AntV ecosystem.
If you are an open-source maintainer or a security operations engineer, you already know the basics of how supply chain attacks function. They typically involve infiltrating a secure system through an outside partner or provider who has legitimate access to your data. However, the techniques utilized in the Mini Shai-Hulud campaign go far beyond the simple typosquatting or dependency confusion attacks we saw in previous years.
The threat actors orchestrated this breach by leveraging a completely compromised maintainer account to publish over 300 malicious packages in a rapid, automated burst. They utilized highly advanced evasion techniques, including orphaned repository commits, cryptographically valid but entirely deceptive provenance attestations, and stealthy machine-level persistence mechanisms designed to survive standard uninstall procedures.
In this comprehensive guide, we will break down exactly how this attack unfolded, the specific mechanisms the hackers employed, the packages affected, and most importantly, a step-by-step remediation guide to ensure your environments and CI/CD pipelines remain secure against this advanced threat.
Understanding the Threat Actor and Past Waves of Attacks
Before diving into the highly technical specifics of the AntV incident, it is essential to understand the adversary behind the code and the history of their operations. The threat group responsible for this incident is known as TeamPCP, a collective that also operates under aliases such as DeadCatx3 and PCPcat. Since late 2025, they have been running a relentless, evolving, and highly targeted campaign dubbed Shai-Hulud.
The Evolution of the Shai-Hulud Campaign
To truly grasp the severity of the current attack, security engineers must look at how TeamPCP has iteratively improved their malware over the past several months. Here is a chronological breakdown of the previous operational waves:
- Wave 1 (September 2025): The primary targets were broad, unspecific npm packages. The scale was relatively small, affecting around 4 packages. However, the signature technique marked a paradigm shift, as it was the introduction of the first self-propagating npm worm, demonstrating the group's ambition to create self-sustaining malware networks.
- Wave 2 (November 2025): The attackers shifted focus to high-value integration targets like Zapier, Posthog, and Postman dependencies. The scale exploded to over 600 packages. The signature technique involved container breakouts and the introduction of a destructive wiper payload, causing significant operational disruption to targeted development environments.
- Wave 3 (April 2026): The primary targets were SAP CAP-JS and MBT. While the scale was small, limited to 4 packages, the signature technique was terrifyingly innovative. This wave introduced a highly targeted AI coding agent hijack, specifically injecting a Claude Code SessionStart hook. This allowed the malware to execute silently whenever a developer interacted with the AI assistant in their local development environment.
- Wave 4 (May 11, 2026): The primary target was the widely used TanStack ecosystem. The scale impacted 84 versions across 42 packages. The signature technique represented a major leap in cryptographic sophistication. The attackers achieved the first valid SLSA provenance via an OIDC hijack, effectively forging a cryptographic seal of approval on their malicious packages to bypass automated security scanners.
- Wave 5 (May 19, 2026): The primary target is the AntV ecosystem and additional interconnected packages. The scale is massive, with 637 versions compromised across 323 packages. The signature technique for this current wave relies on a fully compromised maintainer account and vastly expanded command and control infrastructure.
The AntV Attack Timeline and Affected Packages
The AntV suite is an Alibaba-originated data visualization library heavily utilized in enterprise dashboards, complex financial platforms, and large-scale graph analytics. Because of its massive adoption across enterprise sectors, compromising a maintainer account in this ecosystem provided the attackers with an incredibly lucrative target with a blast radius affecting millions of users.
Attack Timeline on May 19, 2026
The attackers executed their payload delivery with frightening speed, pushing out hundreds of poisoned updates in under 30 minutes to maximize distribution before security vendors could flag the anomalies. All times are recorded in UTC.
- 01:39: The very first malicious package version is successfully published using the compromised atool account.
- 01:56: The first publication wave concludes, successfully pushing approximately 317 malicious versions into the registry.
- 02:05: The second automated publication wave commences.
- 02:06: The second wave concludes almost instantly, adding another 314 malicious versions to the global registry.
- 02:18: Automated detection systems and security researchers identify the anomaly and begin filing urgent incident reports.
- Ongoing: Global investigations continue as the open-source community works to identify further implications, reverse-engineer exfiltration methods, and isolate potential secondary infections.
High-Impact Packages Compromised
The compromised atool account maintained a total of 547 packages. The attacker specifically targeted the most heavily utilized repositories within that portfolio. If your organization relies on any of the following packages, you must assume a potential compromise of your environment:
- size-sensor: Generating over 4.2 million monthly downloads.
- echarts-for-react: Generating over 3.8 million monthly downloads.
- @antv/scale: Generating over 2.2 million monthly downloads.
- timeago.js: Generating over 1.15 million monthly downloads.
- @antv/g6: Generating over 1 million monthly downloads.
Additionally, core scoped packages such as @antv/g2, @antv/x6, @antv/l7, @antv/s2, and highly popular non-scoped packages like canvas-nest.js were heavily impacted by the malicious updates.
The Mechanics: How the Attack Works
To effectively defend against modern software supply chain attacks, security engineers must understand the exact steps hackers take once they gain access to trusted infrastructure. TeamPCP engineered an intricate, seven-stage execution model for the Mini Shai-Hulud attack.
Stage 1: Maintainer Account Compromise
The entire attack hinges on the initial compromise of the atool npm maintainer account. While the exact method of this specific account takeover remains under forensic investigation, the end result was absolute publish access to all 547 packages under the maintainer's control. This effectively bypasses traditional perimeter defenses because the malicious code is downloaded from a trusted, cryptographically authenticated source.
Stage 2: Automated Malicious Publishing
With unrestricted access secured, the attackers used automated scripts to push malicious updates rapidly. Each infected package tarball contained two critical modifications designed for immediate execution and evasion.
First, they included a root-level JavaScript file named index.js. This file was a massive 498KB heavily obfuscated Bun JavaScript payload. Bun is a highly performant modern JavaScript runtime, and compiling the payload in this manner helps the malicious code evade simple static analysis tools that look for traditional Node.js malware patterns.
Second, they modified the package.json file to include a specific preinstall script.
“preinstall”: “bun run index.js”
For DevSecOps engineers less familiar with npm lifecycle hooks, a preinstall script is highly dangerous because it automatically executes the moment a developer types the install command in their terminal, long before the actual package installation process completes. This guarantees the malicious payload executes immediately upon downloading to the local machine or CI server.
Stage 3: Orphan Commit Injection for Sigstore Provenance
This stage represents the most devious and technically advanced aspect of the campaign. The attackers needed their packages to look legitimate to enterprise automated security scanners. They achieved this by injecting an optional dependency that pointed to an orphan commit in the legitimate antvis/G2 repository.
An orphan commit is essentially floating, untracked data. When a user forks a repository on GitHub, makes a code commit, and then deletes the fork, GitHub does not immediately delete the underlying commit data. It remains accessible via its unique cryptographic hash until a background garbage collection process eventually clears it.
The attackers created a fork, authored a commit containing their payload, forged the git author identity to match a real AntV maintainer, and then quickly deleted the fork. They then added the following to their malicious package.json:
“optionalDependencies”: {
“@antv/setup”: “github:antvis/G2#1916faa365f2788b6e193514872d51a242876569”
}
Furthermore, the attackers stole GitHub Actions OIDC tokens. OpenID Connect tokens allow automated pipelines to authenticate with cloud providers without storing long-lived passwords. By hijacking these tokens, the attackers successfully requested legitimate signing certificates from Sigstore.
This resulted in the malicious packages possessing cryptographically valid SLSA Build Level 3 attestations. SLSA is a supply chain security framework. A valid attestation simply proves a package came from a specific pipeline. However, because the attackers compromised the pipeline itself, the security certificate basically verified that the poison was brewed in the correct factory. This highlights a critical lesson: provenance is a measure of origin, not a guarantee of safety.
Stage 4: Credential Harvesting
Once the payload executes on a developer's workstation or within a CI/CD runner pipeline, the malware aggressively shifts to harvesting sensitive data.
The script scans for over 80 specific environment variables and more than 100 system file paths. It targets AWS access keys, GCP service account JSON files, Azure service principal credentials, GitHub personal access tokens, and HashiCorp Vault tokens. It even hunts for database connection strings and SSH keys hidden in local operating system directories.
In a terrifying escalation for CI/CD environments, if the malware finds itself running inside GitHub Actions, it bypasses standard secret masking completely. It achieves this by reading the process memory of the runner worker directly via the Linux memory directory, extracting secrets that were never even formally passed as environment variables.
Stage 5: Data Exfiltration
After gathering the credentials, the malware ensures defenders cannot easily see what was stolen by inspecting network traffic. It serializes the data into JSON, compresses it, and encrypts it using AES-256-GCM. The encryption key itself is then wrapped using an RSA algorithm against a hardcoded public key owned by the attackers.
The data is smuggled out through two primary channels. The first is a command and control server actively disguised as OpenTelemetry trace data. The second is a bizarre but effective GitHub dead-drop system. If the malware steals a GitHub token, it uses it to silently create private repositories on the victim's own account. These repositories are named using terms from the Dune science fiction universe, such as sardaukar, fremen, or atreides. The stolen, encrypted data is quietly committed to these repositories disguised as automated test results.
Stage 6: Persistence
A simple package removal command will not save your environment. The hackers engineered the malware to dig deep into the host machine to maintain control long after the initial infection.
- AI agent hijacking: The malware creates a configuration file for Claude Code. Whenever a developer initiates a new AI coding session in that directory, a hidden startup hook re-executes the malware in the background.
- IDE hooks: It modifies Visual Studio Code configuration files to trigger the malicious script the exact moment a project folder is opened by the developer.
- OS-level daemon: It installs a background process that continuously polls a GitHub search API for new instructions. These commands are cryptographically signed by the attackers, allowing them to execute arbitrary Python code on your machine indefinitely.
- Token monitor: A local shell script constantly checks the status of stolen GitHub tokens, alerting the attackers immediately if a developer attempts to revoke access so the attackers can react quickly.
Stage 7: Worm Propagation
Finally, the malware acts as a self-propagating worm. It searches the infected machine for any npm tokens that have two-factor authentication bypass enabled. It then uses these stolen tokens to infect entirely new packages that the newly compromised developer has access to publish. This is exactly how the infection spreads from one maintainer to another, pushing the malware completely outside the original AntV ecosystem.
Step-by-Step Guide: How to Stay Safe and Remediate
If you suspect your engineering environment came into contact with any of the affected packages between 01:39 and 02:18 UTC on May 19, 2026, you must operate under the assumption of a total environment compromise. Because the exfiltrated data is heavily RSA-encrypted, you cannot verify exactly which secrets were stolen, so everything must be considered exposed.
Follow these strict, step-by-step instructions to remediate the threat and secure your architecture.
Step 1: Remove Persistence Before Revoking Tokens
You must not revoke your tokens before cleaning your local machine. The token monitoring daemon checks your token validity every 60 seconds. If it detects a sudden revocation, it may trigger an aggressive destructive action before you finish cleaning your environment.
Run the following commands to find and securely disable the background daemons:
For Linux systems, disable the systemd service:
For macOS systems, unload the LaunchAgent:
Next, delete the physical daemon scripts from your local user directories:
Step 2: Clean npm and Reinstall on Clean Versions
Remove the physical persistence artifacts left in your project directories. Look closely for the AI agent and IDE hooks.
Check and remove malicious AI configurations:
Check and remove malicious Visual Studio Code tasks. Open your tasks file and remove any task that contains the folderOpen trigger linked to the malware.
Once your environment is physically scrubbed of the persistence hooks, you can clean your npm cache and lockfiles. Delete your node_modules folder entirely. Ensure your dependencies are tightly pinned to safe, verified versions published prior to May 19, 2026.
Step 3: Rotate All Credentials
Now that the persistence mechanisms are definitively destroyed, you must aggressively rotate every single secret the machine or pipeline had access to. This comprehensive rotation includes:
- Cloud provider access keys for AWS, GCP, and Azure.
- GitHub Personal Access Tokens and OIDC configurations.
- npm publish tokens.
- Database connection strings, Slack webhook tokens, and local SSH keys.
Step 4: Audit GitHub for Injected Workflows and Dead-Drops
The attackers may have used your compromised account to store stolen data or propagate the worm further into the ecosystem.
Check your git branches for attacker-injected static analysis workflows:
Check your GitHub account for newly created dead-drop repositories utilizing the Dune naming conventions:
Review your npm audit logs immediately for unexpected or unauthorized package publications:
Step 5: Prevent Future Exposure
To defend your infrastructure against future iterations of the Shai-Hulud campaign, enforce the following policies strictly across your DevSecOps pipeline:
- Enable strict npm two-factor authentication with publish protection on all organizational packages without exception.
- Add the ignore-scripts flag to your CI configuration as an absolute default to prevent preinstall hooks from running automatically during build phases.
- Pin all external dependencies to exact, verified versions using lock files with cryptographic integrity checks.
- Implement a registry cooldown policy, flagging and holding newly published packages in a quarantine state for several days before allowing them into production builds.
- Utilize advanced software composition analysis tools to continuously monitor your dependency tree for malicious packages the moment they are flagged by global threat intelligence networks.
Conclusion
The Mini Shai-Hulud attack on the AntV ecosystem represents a terrifying maturation in software supply chain attacks. The threat actors operating under TeamPCP have clearly moved far beyond simple script kiddie tactics, employing highly sophisticated techniques like SLSA provenance forgery, OpenID Connect hijacking, memory scraping in CI/CD runners, and AI agent manipulation.
For security engineers, DevSecOps professionals, and open-source maintainers operating in 2026, the operational paradigm has fundamentally shifted. Trusting an open-source package simply because it carries a cryptographically valid signature is no longer a viable security posture. We must embrace comprehensive defense-in-depth strategies, aggressively auditing our CI/CD pipelines, proactively monitoring for deeply embedded persistence mechanisms, and treating every single third-party dependency update as a potential vector for high-stakes credential theft. By understanding the granular mechanics of these advanced attacks and strictly adhering to modern remediation protocols, we can actively protect our infrastructure from the relentless and evolving waves of supply chain threats.
