What happened#
A new Mini Shai-Hulud supply-chain campaign has hit hundreds of open-source packages, according to reporting from SecurityWeek and findings cited from Microsoft, Socket, Wiz, and StepSecurity.
The initial known compromise involved the npm maintainer account atool. That account had access to multiple packages under the @antv namespace and also publishes timeago.js, a package SecurityWeek says has about 1.5 million weekly downloads.
After the account was compromised, attackers used it to publish malicious package versions. The attack then spread downstream into other popular packages, including echarts-for-react, listed in the source at roughly 1.1 million weekly downloads.
The reported impact is larger than a single namespace. Microsoft observed roughly 639 malicious versions across affected packages in data visualization, graphing, mapping, charting, and React component ecosystems. Socket reported tracking 1,055 versions across 502 unique packages in the broader campaign. Socket’s count spans npm, PyPI, and Composer, with npm representing nearly all of the activity: 1,048 npm versions across 498 unique npm packages, plus six PyPI entries across three packages and one Composer package-version entry.
The campaign also touched GitHub Actions and a VS Code extension, according to the source. Wiz linked a compromise of the popular GitHub Action actions-cool/issues-helper to the same activity. StepSecurity reported that Microsoft’s Durabletask Python SDK was also affected, with three malicious versions uploaded to PyPI within a 35-minute window.
Those details matter because this is not only a package registry issue. The payloads targeted developer machines, build systems, and CI/CD environments where secrets often exist in memory, config files, or environment variables.
What the payload did#
Most affected packages were reportedly under the @antv namespace and carried an install-time payload. That means the malicious code could run when the package was installed, before any application code explicitly imported or used it.
SecurityWeek cites researchers saying the attack used a multi-stage infection chain. Initial payloads fetched additional code from GitHub-hosted infrastructure. Secondary payloads were designed to steal credentials and establish persistence.
Socket described the payload as obfuscated and capable of reading GitHub Actions runner process memory to extract masked CI/CD secrets in plaintext. That is a key point. CI systems often mask secrets in logs, but masking output is not the same as protecting the secret from a malicious process running on the same runner.
The same payload reportedly harvested credentials from more than 130 file paths. The targeted material included cloud credentials and developer secrets tied to AWS, GCP, Azure, Kubernetes, HashiCorp Vault, cryptocurrency wallets, and developer tooling.
The stolen data was exfiltrated through two channels. As in earlier Mini Shai-Hulud activity, researchers observed exfiltration through GitHub repositories and through a fallback server. StepSecurity also identified more than 2,200 GitHub repositories containing exfiltrated data, according to the source.
Socket also reported npm registry abuse logic inside the malware. The code could validate npm tokens through registry APIs, enumerate packages maintainable by the token owner, download package tarballs, inject the malicious payload, add a preinstall hook, bump package versions, and republish modified packages under the compromised maintainer’s identity.
That behavior explains how this type of campaign can move fast. Once a token or maintainer account is compromised, the attacker can use the registry itself as a distribution mechanism. The next wave does not require tricking every project individually. It can ride through existing trust relationships.
What appears different this time#
The source describes this as a fresh Mini Shai-Hulud supply-chain attack, with similarities to earlier campaigns. The exfiltration pattern through GitHub repositories and a fallback server appears consistent with previous activity.
But researchers also reported changes.
Wiz said the malware was seen downloading and executing Python code from attacker-controlled infrastructure. That gives operators ongoing remote execution capability on compromised systems, rather than only a one-time install-time theft event.
StepSecurity also observed persistent backdoors being dropped into Claude Code. The source does not provide enough detail to describe the exact persistence method or the full scope of those backdoors. The safe conclusion is narrower: researchers saw behavior that went beyond simple credential harvesting and moved toward durable access on selected systems.
That raises the operational risk. If an affected CI runner or developer machine installed one of the malicious package versions, rotating npm tokens alone may not be enough. A host that executed a second-stage payload may need deeper inspection, rebuild, or replacement, depending on the environment and exposure.
Why developers and security teams should care#
The most important lesson is not that npm is unsafe. It is that modern build chains concentrate trust in a small number of accounts, tokens, install scripts, and automation paths.
A popular frontend package can sit inside thousands of applications. A maintainer token can publish to many packages. A GitHub Actions runner can hold cloud credentials, deployment tokens, npm tokens, Kubernetes configs, and repository secrets. A single malicious preinstall path can cross those boundaries quickly.
This campaign is also a reminder that download counts are not a security signal. Packages with millions of weekly downloads can still become attack paths if a maintainer account or publishing credential is compromised. Popularity may increase exposure because the package is already allowed through dependency policies and cached across build systems.
The attack also weakens a common assumption about CI secrets. Many teams treat secret masking as a strong control. It is mostly a log hygiene control. If malicious code runs inside the same job or runner context, it may be able to access secrets before they ever reach a log.
What to check now#
Teams that use npm, PyPI, Composer, GitHub Actions, or VS Code extensions in build workflows should not treat this as only an npm cleanup task.
Practical checks:
- Review whether your dependency tree included affected
@antvpackages,timeago.js,echarts-for-react, Microsoft Durabletask Python SDK versions identified by researchers, or theactions-cool/issues-helperGitHub Action during the relevant window. - Inspect package lockfiles, build logs, dependency cache entries, and artifact provenance for unexpected versions published during the campaign.
- Look for install-time script execution, especially
preinstallhooks added in unexpected package versions. - Rotate npm, PyPI, GitHub, cloud, Kubernetes, Vault, and deployment credentials that may have been available to affected developer machines or CI runners.
- Treat self-hosted CI runners as potentially contaminated if they installed affected versions. Rebuild clean runners where practical.
- Search GitHub organizations for unknown repositories, suspicious commits, or repositories containing dumped secrets.
- Review npm tokens for scope, age, automation use, and package ownership. Remove tokens that are broader than needed.
- Pin GitHub Actions to full commit SHAs where possible, especially for third-party actions used in sensitive workflows.
The exact response should depend on exposure. A project that only resolved a compromised package in a local sandbox has a different risk profile from a production deployment pipeline that installed it with cloud and registry tokens present.
What not to overclaim#
The public reporting does not prove that every package version counted by researchers led to successful compromise in every consuming environment. Presence in a dependency tree is not the same as confirmed secret theft.
It also does not establish one uniform impact across npm, PyPI, Composer, GitHub Actions, and VS Code. The campaign appears coordinated across several surfaces, but the mechanics and exposure vary by ecosystem.
Attribution should also be handled carefully. The source references similarities to previous Mini Shai-Hulud attacks and mentions the infamous group context, but the practical issue for defenders is immediate: malicious package versions, credential theft, registry abuse, and possible persistence.
Bottom line#
This campaign shows why supply-chain defense cannot stop at dependency scanning.
The weak point is the full path: maintainer account, package registry, install script, CI runner, secrets, publishing token, and downstream package ownership. Mini Shai-Hulud abused that path as a system.
The defensive response should do the same. Check dependency exposure. Rotate reachable secrets. Rebuild affected runners. Reduce token scope. Treat install scripts and third-party actions as code execution, because that is what they are.