Mini Shai-Hulud Worm Compromises TanStack, Mistral AI, Guardrails AI, and Other Projects
Software supply chain attacks are getting more sophisticated by the day, and the latest campaign from the TeamPCP group is a crystal-clear example of that.
Dubbed Mini Shai-Hulud, the offensive compromised packages from projects like TanStack, Mistral AI, Guardrails AI, UiPath, and OpenSearch, along with dozens of others distributed via npm and PyPI.
The numbers are staggering: over 170 affected packages and an eye-popping 518 million downloads accumulated across the compromised versions. At least 400 repositories with stolen credentials were created as part of the attack wave, all containing the string Shai-Hulud: Here We Go Again.
This is not your average attack.
We are looking at a worm with self-propagation capabilities that spreads across the entire supply chain without needing to steal traditional publishing tokens, exploiting credentials and legitimate CI/CD infrastructure to move from one maintainer to another in a nearly invisible way.
What stands out here is not just the scale but the engineering behind the attack.
For the first time in a documented case, malicious packages were published with valid SLSA Build Level 3 provenance — the very set of guarantees that should signal the exact opposite: that the software is trustworthy and that the build process has not been tampered with.
Multiple reports from companies including Aikido Security, Endor Labs, SafeDep, Socket, StepSecurity, and Snyk confirmed the technical details of the campaign. Throughout this article, we will break down how all of this worked in practice, which projects were compromised, what the malware does once installed, and what developers need to know right now to protect their environments. 🔍
How Mini Shai-Hulud Spread Across the Supply Chain
To understand the severity of what happened, you need to understand the logic behind the Mini Shai-Hulud movement. Unlike conventional attacks where a malicious actor needs to individually compromise each maintainer account or steal authentication tokens, this worm operates in a far smarter and more alarming way. It acts within already-authorized continuous integration environments, leveraging CI/CD pipelines that the projects themselves use on a daily basis to build and publish versions. This means the malicious code circulates with all the permissions it needs, without triggering immediate alarms in traditional detection systems.
The self-propagation mechanism is the core of everything. When the worm gains access to a maintainer’s build environment, it does not sit idle. It locates a publishable npm token with the bypass_2fa setting set to true, enumerates all packages published by the same maintainer, and exchanges a GitHub OIDC token for a package-specific publishing token, completely bypassing traditional authentication. From there, it replicates the malicious behavior to those new environments, publishing compromised versions to registries like npm and PyPI in a fully automated fashion. This entire cycle happens without direct human interaction, which explains the speed at which the attack reached over 170 packages in a relatively short window of time.
Receive the best innovation content in your email.
All the news, tips, trends, and resources you're looking for, delivered to your inbox.
By subscribing to the newsletter, you agree to receive communications from Método Viral. We are committed to always protecting and respecting your privacy.
The technique used in the TanStack ecosystem is particularly clever. According to the post-mortem analysis published by TanStack itself, the compromise involved a chained attack via GitHub Actions that exploited the pull_request_target trigger, GitHub Actions cache poisoning, and runtime extraction of an OIDC token directly from the runner process memory. The attackers prepared the malicious payload in a GitHub fork through an orphan commit, injected the code into the tarballs published to npm, and then hijacked the legitimate TanStack/router workflow to publish the compromised versions with valid SLSA provenance.
What makes this campaign even more concerning is precisely the fact that the published packages carried valid SLSA Build Level 3 provenance. The SLSA framework, which stands for Supply Chain Levels for Software Artifacts, was created to offer guarantees about the integrity of the software build process. A package with this certification should, in theory, be safe, traceable, and free from tampering. But because the attack operated within legitimate infrastructure, it managed to generate this provenance in a technically correct way, fooling even the most rigorous verification mechanisms.
As researcher Peyton Kennedy from Endor Labs explained, the orphan commit triggered a GitHub Actions workflow execution against the legitimate TanStack/router surface. Since the OIDC trusted publisher configuration granted trust at the repository level — without scoping it to a protected branch or specific workflow file — the workflow triggered by that commit was able to request a valid, short-lived npm publishing token.
This is the first time this kind of bypass has been documented at real-world scale, and it redefines what the community understands as a security guarantee in automated builds. 😬
TanStack, Mistral AI, and Guardrails AI Among the Compromised Projects
TanStack is one of the most popular ecosystems in the modern JavaScript world. Projects like TanStack Query, TanStack Router, and TanStack Table are used by thousands of production applications around the globe, with daily downloads in the millions. The TanStack compromise received the identifier CVE-2026-45321, with a CVSS score of 9.6 out of 10.0, indicating critical severity. The incident impacted 42 packages and 84 versions across the entire TanStack ecosystem.
When a package with that level of adoption is compromised, the potential impact goes far beyond direct download numbers. Developers who use these libraries as dependencies in their own projects also end up exposed without knowing it, creating a cascading effect that multiplies across the entire software production chain.
TanStack stated that they traced the compromise and confirmed that no npm tokens were directly stolen and that the npm publishing workflow itself was not compromised. The attack vector was the chained exploitation of the GitHub Actions and OIDC system.
The Technical Approach Varied Across Targets
An important technical detail is that the attack approach varied between different targets. In the case of TanStack, unlike the earlier wave that hit SAP packages — where the compromised packages added a preinstall hook to trigger the infection sequence — the TanStack cluster adopted a different strategy. The packages included a JavaScript file inside the tarball and added an optional dependency pointing to a package hosted on GitHub. That dependency contained a prepare lifecycle hook that executed the JavaScript payload through the Bun runtime.
The updates to Mistral AI packages followed the earlier approach, replacing the package.json content with a preinstall hook to invoke node setup.mjs, which downloaded Bun and executed the same JavaScript malware.
In the case of Mistral AI, the situation has an additional layer of complexity. The company is one of the most relevant players in the current large language model landscape, and its official packages are used by developers integrating artificial intelligence capabilities into applications and services. Microsoft’s analysis of the malicious mistralai package on PyPI revealed it was designed to download a credential stealer from a remote server and includes country-based reconnaissance logic to avoid Russian-language environments, plus a destructive geofenced branch that has a 1-in-6 chance of executing the rm -rf / command when the system appears to be in Israel or Iran.
The compromise of Guardrails AI in version 0.10.1 on PyPI is especially notable because the malicious code executes on import. The package checks whether it is running on Linux systems, downloads a remote Python artifact, saves it to /tmp/transformers.pyz, and executes it with python3 without any integrity verification.
Complete List of Identified Compromised Packages
Beyond TanStack and Mistral AI, the campaign spread to several other packages, including some on PyPI:
- [email protected] (PyPI)
- [email protected] (PyPI)
- @opensearch-project/[email protected], 3.6.2, 3.7.0, and 3.8.0
- @squawk/[email protected]
- @squawk/[email protected]
- @squawk/[email protected]
- @tallyui/[email protected], 1.0.2, and 1.0.3
- @tallyui/[email protected], 1.0.2, and 1.0.3
According to data from OX Security, the incident affected more than 170 packages across both the npm and PyPI registries. The diversity of targets suggests that the group’s strategy was not to focus on a single ecosystem but rather to map connections between maintainers and projects to maximize the reach of each new entry point gained. This systematic approach is what sets Mini Shai-Hulud apart from previous campaigns. 🔐
What the Malware Does Once Installed
Once a compromised package is installed in a developer’s environment or in a CI/CD pipeline, Mini Shai-Hulud begins operating on multiple fronts. The affected npm packages were modified to include an obfuscated JavaScript file called router_init.js, designed to analyze the execution environment and launch a comprehensive credential stealer capable of targeting cloud providers, cryptocurrency wallets, AI tools, messaging applications, and CI systems, including GitHub Actions.
The collected data is exfiltrated to the domain filev2.getsession.org. The use of Session Protocol infrastructure is a deliberate attempt by the attackers to evade detection, since the domain is unlikely to be blocked in corporate environments because it belongs to a decentralized, privacy-focused messaging service.
Multiple Persistence Mechanisms
The malware demonstrates a remarkable level of sophistication in the persistence mechanisms it implements:
- Claude Code and VS Code persistence hooks: The malware installs itself in a way that survives system reboots and re-executes every time the IDEs are launched.
- gh-token-monitor service: A dedicated service that continuously monitors and re-exfiltrates GitHub tokens.
- Malicious GitHub Actions workflows: Two workflows are injected to serialize repository secrets into a JSON object and upload the data to an external server at api.masscan.cloud.
- GraphQL fallback: As an alternative option, encrypted data is committed to attacker-controlled repositories under the author name [email protected] through the GitHub GraphQL API, using the stolen tokens.
The Dead-Man’s Switch: A Trap for Those Who Try to Respond
One of the most aggressive and unprecedented behaviors introduced in this campaign is the installation of a dead-man’s switch. It is a shell script that periodically checks whether an npm token created by the malware has been revoked, querying the api.github.com/user endpoint every 60 seconds. The token carries the provocative description IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner.
If the developer revokes the token through the npm dashboard, the script triggers a destructive routine that executes rm -rf ~/ on the infected machine, essentially turning the malware into a wiper. These changes indicate that TeamPCP is becoming more aggressive and evolving its techniques with each new campaign.
This is extremely important: developers should not revoke npm tokens before isolating and creating a forensic image of the system. Reacting hastily could result in the complete destruction of the machine’s data. 🚨
Why This Attack Changes the Rules of the Game
The TeamPCP group demonstrated a level of technical sophistication that goes beyond what we have seen in previous supply chain attack campaigns. The combination of self-propagation, use of legitimate infrastructure, and generation of valid SLSA provenance creates a scenario where traditional defenses simply are not enough. Vulnerability scanning tools that rely on known signatures fail to detect the problem because the malicious code arrives wrapped in technically correct processes.
As researcher Ashish Kurmi from StepSecurity highlighted, the attack published malicious versions through the project’s own GitHub Actions release pipeline using hijacked OIDC tokens. In an extremely rare escalation, the compromised packages carry valid SLSA Build Level 3 provenance attestations, making this the first documented npm worm that produces malicious packages with validly issued attestation.
Avital Harel, security research lead at Upwind, put the severity into context well: this campaign reflects a broader shift in supply chain attacks, moving from isolated package compromise to identity-driven propagation through trusted CI/CD infrastructure. Once attackers gain access to publishing workflows and pipeline identities, the software delivery process itself becomes the distribution mechanism. The challenge for defenders is that much of this activity can look legitimate on the surface, which makes behavioral visibility during installations and builds increasingly important.
What Developers Need to Know Right Now
The first thing any developer or engineering team needs to understand is that valid provenance is no longer synonymous with absolute security. The fact that Mini Shai-Hulud managed to publish packages with legitimate SLSA Build Level 3 certification forces the community to reassess the weight that guarantee carries within a security evaluation process. This does not mean abandoning the use of frameworks like SLSA, which remain valuable tools within a broader strategy. It means they need to be treated as one verification layer among many, and not as a definitive attestation that a package is safe for production use.
Practices like frequent dependency auditing, using up-to-date lockfiles, and active monitoring of changes in the packages you use are more important than ever. Tools that alert you to unexpected new version publications, especially in widely used packages, can be a critical differentiator for detecting suspicious activity before it spreads through your environment.
Practical Steps to Protect Your Environment
- Do not revoke npm tokens immediately if you suspect compromise. Isolate and create a forensic image of the system first to avoid triggering the dead-man’s switch.
- Review OIDC trusted publisher configurations to ensure trust is scoped to protected branches and specific workflow files, not to the entire repository.
- Audit secrets stored in CI/CD pipelines and implement the principle of least privilege for publishing tokens.
- Monitor unexpected publications in packages you maintain or depend on, especially versions that appear outside the normal release cycle.
- Implement behavioral checks that analyze what packages do at runtime, not just what they appear to be at install time.
- Check your dependencies against the lists of compromised versions published by the security firms that analyzed the campaign.
Security commitments need to evolve alongside threats. Campaigns like Mini Shai-Hulud show that attackers are investing time and technical expertise to understand exactly how the open source ecosystem’s trust systems work — and then exploiting those very mechanisms. The community’s response cannot be any less sophisticated than that.
As Socket’s analysis highlighted, this latest activity shows the campaign continuing to propagate across both npm and PyPI, with affected packages spanning search infrastructure, AI tools, aviation-related development packages, enterprise automation, frontend tools, and CI/CD-adjacent ecosystems.
Software supply chain security has become, once and for all, a collective responsibility that demands continuous attention and active collaboration among maintainers, companies, and the security community. Mini Shai-Hulud is not just another incident on the growing list of supply chain attacks. It is an inflection point that demonstrates how automated trust, when exploited by sophisticated actors, can become the biggest vulnerability in the entire ecosystem. 🛡️
