In just 22 minutes, the npm ecosystem was pressed with the "fast release" key: an account named atool was compromised, and the attacker took over its publishing rights, scriptively pushing 637 malicious new versions to 317 npm packages, which Slow Fog named the Mini Shai-Hulud “mini sandworm” supply chain attack. Unlike traditional intrusions, this was a poisoning that occurred during the dependency publishing and distribution phase, following seemingly normal version updates down the trust chain. Slow Fog pointed out in the latest threat intelligence that the affected were not just obscure packages, but also high-frequency dependencies such as AntV, Echarts-for-react, and the Python SDK durabletask, among others. Components like AntV, with millions of monthly downloads on npm, have already become “infrastructure” for front-end and data dashboards. With a large number of Web3 and blockchain projects relying on these npm components for front-end interfaces, visualization dashboards, and operational tools, a supply chain attack on high-frequency packages means that developers could unwittingly bring the “mini sandworm” into their development environments and project dependency chains through daily upgrades.

637 Versions in 22 Minutes: Automated Poisoning Arrives

When security researchers traced back suspicious clues, the timeline compressed into a seemingly unreasonable straight line: the npm account atool was hacked, publishing rights fell into the hands of the attacker, and a script took over everything. Records disclosed by Slow Fog show that within about 22 minutes, the stolen account used an automated script to continuously push 637 new versions to 317 npm packages—each “version upgrade” was essentially a precision poisoning. No one could manually open hundreds of packages in such a short time to modify and publish them one by one; this rhythm could only come from a pre-prepared batch publishing program: reading the existing package list, looping to modify version numbers and dependencies, building and uploading until the “mini sandworm” was buried into as many distribution points as possible.

This is a typical form of supply chain attacks in the development ecosystem: attackers do not target each front end, each dashboard, or each blockchain interaction logic individually, but specifically focus on the dependency distribution phase. In npm, the most widely used package manager in the JavaScript ecosystem, as long as control is established over the publishing or updating phase, injecting malicious code into the package means that all downstream applications will integrate the contaminated dependencies into their codebases whenever they execute routine npm installations and updates, completely unawares. Compared with single-point intrusions, this high-speed, mass poisoning method directly misaligns with existing development processes: automated CI/CD only looks at whether the version number is updated, developers only care whether the functionality works normally, and manual reviews cannot keep up with the pace of 22 minutes and 637 versions. By the time someone notices an anomaly, the “mini sandworm” has probably already crawled through countless projects and environments via this supply chain.

High-Frequency npm Dependencies Contaminated: Front-End to Python All Affected

The ones named are not just a few obscure libraries. Visual components like AntV and Echarts-for-react have long become the “infrastructure” for front-end development: from K-line and depth charts on trading terminals, to operational dashboards in project background systems, to the data dashboards for multi-chain analysis platforms, Web2 and Web3 teams are accustomed to directly pulling these dependencies from npm. Research briefs mention that packages like AntV have reached millions of monthly downloads on npm. Once the maintainer's account is compromised and the versions are quietly replaced, the potential impact is on thousands of front-end build pipelines—CI auto-pulls new versions, front-end engineers only see “build passed, page rendered normally,” yet it is difficult to realize that they have pushed contaminated chart components onto production servers.

Worse yet, this “mini sandworm” is not content with just the front-end ecosystem. Slow Fog disclosed that the Python SDK durabletask is also listed as an affected project, indicating that the attack path has extended beyond the browser interface, reaching deeper technical stacks like task orchestration and backend services. Unverified messages from security communities indicate that several new versions of durabletask might have malicious code embedded, and such rumors alone are enough to compromise the safety of automated processes, on-chain data processing scripts, and monitoring services that rely on it. For many teams, updating these dependencies is merely routine maintenance—changing a line version number, running tests, merging code—there is no explicit “danger moment” at any stage, but it is precisely this unconscious, cross-language synchronized poisoning that leads developers to unwittingly introduce attackers into their systems through what they believe to be safe maintenance operations.

When Blockchain Meets npm: Web3 Development Environment Involved

When Slow Fog, known for on-chain security, unusually targeted the npm and Python ecosystems in their warning, the ones truly named were not merely a few packages, but the entire development chain relied upon by Web3 teams. The research brief clearly states that this is a supply chain security attack: the attackers do not directly strike on-chain contracts, but lurk in the dependency publishing and distribution phases, using trusted update channels to send the “mini sandworm” downstream through version numbers into each downstream pipeline. The reason Slow Fog issued cross-ecosystem warnings is that this attack path naturally penetrates the Web2/Web3 divide—npm is one of the most widely used package managers in the JavaScript ecosystem, and most blockchain projects’ fronts, scripts, and tools share the same batch of underlying infrastructure with traditional internet projects.

The “shared bones” for Web3 are buried deep enough. Many on-chain projects’ front-end panels, management backgrounds, and data displays routinely use visualization components like AntV and Echarts-for-react to render on-chain transactions, node statuses, and indicator charts, with these high-frequency components having millions of monthly downloads on npm. Once contaminated, what is truly exposed is not the charts themselves, but the machines that host them: the control console used by operations to manage nodes, the visual dashboards that the quant team uses to monitor strategy performance, the operational backgrounds of internal wallet management tools. Delving further, scripts responsible for automated deployment, report generation, and bulk node operations are mostly written in JavaScript/TypeScript or Python, which also need to pull dependencies from npm or related ecosystems. As long as any link among them gets embedded with malicious dependencies, attackers have a foothold in the “development” and “operations” areas—those closest to private keys, node permissions, and monitoring alert configurations—indirectly impacting the security boundaries of critical components like wallets, node management, and monitoring platforms.

Repeated Breakage of Open Source Trust: Starting from the Colors Incident

Such risks did not first emerge with the “mini sandworm.” The research brief mentions that the “colors/faker” incident in 2024 caused a massive collapse of applications globally that relied on these two libraries: developers, intentionally or unintentionally, pushed new versions with destructive logic onto mainstream dependencies, resulting in what appeared to be a normal update triggering chain reactions downstream. For countless developers, behind a line of `npm install` is a default trust that open-source maintainers “won't harm me”; yet in the colors/faker incident, this layer of default trust was first ripped at a large scale, making it clear just how fragile the open-source supply chain is.

The “mini sandworm” attack merely ripped the same wound even wider. In this incident, the npm account atool was hacked, and the attacker gained the capability to publish versions on multiple npm packages, automatically pushing 637 malicious versions to 317 npm packages within about 22 minutes, affecting high-frequency dependencies like AntV, Echarts-for-react, and durabletask. Like colors/faker, the malicious code did not originate from a single-point breach of an application; rather, it rode the coattails of “normal updates,” continuously infiltrating downstream from trusted publishing channels. The research brief delineates these two types of incidents side by side, as typical samples of systemic risks in the open-source supply chain: in retrospect, everyone reflects on dependency management and discusses version locking and security scanning, but in actual engineering, teams' defenses against supply chain security remain insufficient. Incidents repeatedly prove that the default trust upon which the open-source world operates is continuously eroded; relying only on maintainers' reputations, project stars, and download counts is no longer sufficient to draw reliable security boundaries around any dependency graph.

From Luck to Normalized Defense: How Developers Can Protect Themselves

The “mini sandworm” pushed 637 malicious versions to 317 packages in 22 minutes; what’s truly exposed is not the negligence of a single account but the common shortcoming in dependency management among Web2 and Web3 teams: an unqualified full trust in the npm ecosystem, reliance on automatic updates, and intuitive judgments of “whoever downloads more is the one to trust,” lacking visibility into dependency chains, and missing psychological expectations of treating supply chain attacks as high-frequency threats. The colors/faker incident has already proven that once any upstream is tampered with, it can topple countless applications globally; the recent poisoning of the open-source ecosystem indicates that this is not an isolated phenomenon, but an attack path that can be continually reused. In practical engineering, the self-protection mindset at the team level must shift from “trusting maintainers” to “minimal trust”: locking dependency versions and lock files to reduce exposure to unexpected upgrades, utilizing dependency security scanning and software bill of materials, ensuring at least knowledge of which packages the project introduces and where they come from, and combining internal whitelisting with manual sampling of critical dependencies to add another gate for high-risk components. At the same time, it’s essential not to place hope solely on the ethical and vigilance of individual package maintainers; rather, the threat intelligence from security organizations like Slow Fog has to be integrated into the process—once any npm account or popular package is named, one can quickly cross-check against their own SBOM and lock files to determine if they have been compromised and execute rollbacks. Looking forward in the development cycle, supply chain attacks will likely persist in the long term; blockchain projects, due to their heavy reliance on npm and other traditional ecosystems for front-end, visualization, and operational tools, need to treat this layer of risk as a normalized backdrop in overall security planning, rather than an exception that won’t occur if they are lucky.

Join our community to discuss and become stronger together!
Official Telegram community: https://t.me/aicoincn
AiCoin Chinese Twitter: https://x.com/AiCoinzh
OKX Benefits Group: https://aicoin.com/link/chat?cid=l61eM4owQ
Binance Benefits Group: https://aicoin.com/link/chat?cid=ynr7d1P6Z

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。