A single worm has spread across both npm and PyPI, it compromised packages from major companies like TanStack, UiPath, Mistral AI, and OpenSearch, and it used the projects' own trusted publishing systems to do it.
The TeamPCP supply chain worm is part of a fresh Mini Shai-Hulud campaign, and multiple security firms including Aikido Security, Endor Labs, SafeDep, Socket, StepSecurity, and Snyk have all published analyses of the same ongoing attack.
The TeamPCP supply chain worm modified npm packages to include an obfuscated JavaScript file called router_init.js, this file profiles the execution environment, launches a comprehensive credential stealer, and targets cloud providers, cryptocurrency wallets, AI tools, messaging apps, and CI systems including GitHub Actions.
How the Worm Spreads
The TeamPCP supply chain worm has an unusual self-spreading mechanism, it locates a publishable npm token with bypass_2fa set to true, enumerates every package published by the same maintainer, and exchanges a GitHub OIDC token for a per-package publish token, sidestepping traditional authentication entirely.
Unlike previous supply chain attacks that stole npm tokens directly, the TeamPCP supply chain worm abuses trusted publishing, this allows attacker-controlled code running within a GitHub Actions workflow to leverage its OIDC permissions and mint a short-lived publish token during the build, then use that token to publish malicious packages.
This technique means the TeamPCP supply chain worm does not need to steal long-lived npm tokens at all, it simply borrows the credentials that the legitimate build process already has.
The TanStack Compromise
The TeamPCP supply chain worm hit TanStack particularly hard, and this compromise has been assigned CVE-2026-45321 with a CVSS score of 9.6 (Critical).
TanStack traced the compromise to a chained GitHub Actions attack involving the pull_request_target trigger, GitHub Actions cache poisoning, and runtime memory extraction of an OIDC token from the GitHub Actions runner process, and notably TanStack confirmed that no npm tokens were stolen and the npm publish workflow itself was not compromised.
The TeamPCP supply chain worm staged the malicious payload in a GitHub fork via an orphaned commit, injected it into published npm tarballs, and then hijacked the project's legitimate TanStack/router workflow to publish the compromised versions.
Because the repository's OIDC trusted publisher configuration granted trust at the repository level rather than being scoped to a specific protected branch and workflow file, the TeamPCP supply chain worm was able to request valid short-lived npm publish tokens.
The attack impacted 42 packages and 84 versions across the TanStack ecosystem, making this one of the largest single-supply chain compromises in recent memory.
Valid SLSA Provenance on Malicious Packages
In an extremely rare escalation, the TeamPCP supply chain worm compromised packages carry valid SLSA Build Level 3 provenance attestations, and this makes it the first documented npm worm that produces validly attested malicious packages.
SLSA (Supply-chain Levels for Software Artifacts) provenance is supposed to help users verify that a package came from a legitimate build process, but the TeamPCP supply chain worm abused the system to make malicious packages look authentic.
When a security tool checks the SLSA attestation on a malicious TanStack package, it sees a valid signature from the legitimate TanStack build process, and this makes automated detection dramatically harder.
The Credential Stealer Capabilities
The TeamPCP supply chain worm includes a comprehensive credential stealer with wide-ranging targets.
1. Local configuration files or environment variables allow users to obtain credential information in order for them work with cloud services such as: Amazon Web Services (AWS), Google Cloud and Microsoft Azure.
2. Cryptocurrency wallet files and seed phrases are also being stolen from people by such programs called stealers.
3. The access credential data, as well as the access token for AI tools (Claude Code, various other AI Applications), are also being stolen.
4. Online messaging applications do experience theft of their session tokens and/or session data as well.
5. CI Systems (GitHub Actions) are also being targeted by the TeamPCP supply chain worm, stealing GitHub tokens, and injecting malicious workflows.
Browser data from multiple browsers is harvested including saved passwords and cookies.
Exfiltration via Session Protocol
The TeamPCP supply chain worm exfiltrates stolen data to filev2.getsession[.]org, which belongs to the Session Protocol infrastructure, and Session is a decentralized, privacy-focused messaging service.
Using Session Protocol is a deliberate evasion technique because the domain is unlikely to be blocked within enterprise environments, security teams are cautious about blocking privacy tools, and the attackers exploit that caution.
As a fallback option, the TeamPCP supply chain worm commits encrypted data to attacker-controlled repositories under the author name [email protected] via the GitHub GraphQL API using stolen GitHub tokens.
Persistence in Development Environments
The TeamPCP supply chain worm establishes persistence hooks in Claude Code and Microsoft Visual Studio Code (VS Code), and this allows the malware to survive reboots and re-execute the stealer on every launch of the IDEs.
Developers who use VS Code or Claude Code and who installed a compromised package will have the TeamPCP supply chain worm re-activate every time they open their editor, even after cleaning other parts of the infection.
The worm also installs a gh-token-monitor service to monitor and re-exfiltrate GitHub tokens, and it injects two malicious GitHub Actions workflows to serialize repository secrets into a JSON object and upload the data to an external server at api.masscan[.]cloud.
The Mistral AI and Guardrails AI Compromises
The TeamPCP supply chain worm spread beyond npm into PyPI, affecting packages from Mistral AI and Guardrails AI.
The malicious [email protected] PyPI package includes country-aware logic to avoid Russian-language environments, and it has a geofenced destructive branch with a 1-in-6 chance of executing rm -rf / when the system appears to be in Israel or Iran.
Microsoft analyzed this package and confirmed the destructive payload, the TeamPCP supply chain worm operators are not just stealing data, they are prepared to destroy systems in specific geopolitical regions.
The [email protected] compromise is especially notable because the malicious code executes on import, the package checks for Linux systems, downloads a remote Python artifact from https://git-tanstack.com/transformers.pyz, writes it to /tmp/transformers.pyz, and executes it with python3 without any integrity verification.
Other Affected Packages
The TeamPCP supply chain worm has spread to several other packages across both ecosystems.
Affected npm packages include:
@opensearch-project/opensearch versions 3.5.3, 3.6.2, 3.7.0, and 3.8.0
@squawk/[email protected]
@squawk/[email protected]
@squawk/[email protected]
@tallyui/connector-medusa versions 1.0.1, 1.0.2, and 1.0.3
@tallyui/connector-vendure versions 1.0.1, 1.0.2, and 1.0.3
Affected PyPI packages include:
[email protected]
[email protected]
The TeamPCP supply chain worm now spans search infrastructure (OpenSearch), AI tooling (Mistral AI, Guardrails AI), aviation-related developer packages, enterprise automation, frontend tooling (TanStack), and CI/CD-adjacent ecosystems.
Comparison to Previous SAP Wave
Unlike the previous SAP wave where compromised packages added a preinstall hook to trigger the infection sequence, the TeamPCP supply chain worm TanStack cluster uses a different strategy.
The worm includes a JavaScript file within the package tarball and adds an optional dependency that points to a GitHub-hosted package, and the GitHub dependency contains a prepare lifecycle hook that executes the JavaScript payload via the Bun runtime.
The Mistral AI packages follow the earlier approach, replacing the contents of package.json with a preinstall hook to invoke node setup.mjs, which downloads Bun and runs the same JavaScript malware.
The TeamPCP supply chain worm operators are adapting their techniques based on the target package and ecosystem.
How the Attack Works Step by Step
The TeamPCP supply chain worm follows a sophisticated multi-stage attack chain.
Stage 1: Initial compromise. The attackers find a GitHub repository with a vulnerable pull_request_target workflow, they fork the repository and create an orphaned commit containing malicious code.
Stage 2: Workflow hijacking. The TeamPCP supply chain worm triggers a GitHub Actions workflow run against the legitimate repository's workflow surface, because OIDC trust is granted at the repository level, the compromised workflow can request publish tokens.
Stage 3: Package publication. The workflow uses its OIDC token to mint short-lived npm publish tokens, and the TeamPCP supply chain worm publishes malicious package versions with valid SLSA provenance.
Stage 4: Credential harvesting. When developers install the compromised packages, the obfuscated JavaScript payload executes, it profiles the environment, steals credentials, and exfiltrates them via Session Protocol.
Stage 5: Self-propagation. The TeamPCP supply chain worm finds publishable npm tokens on compromised systems, enumerates all packages by the same maintainer, and repeats the OIDC token exchange to publish more malicious packages.
Why This Worm Is Unprecedented
The TeamPCP supply chain worm has several characteristics that make it unique.
1. Valid SLSA provenance on malicious packages means traditional provenance verification does not catch this worm, and this is the first documented npm worm with valid attestations.
2. The OIDC token exploitation does not require an npm token to be compromised, and the supply chain worm TeamPCP uses the legitimate build system's own permissions to exploit the system.
3. Inter-ecological Propagation is the fact that the worm is distributing itself through the npm and PyPI ecosystems and that the worm's creators are not limiting themselves to only one programming language.
4. Geofenced destructive payloads show that the TeamPCP supply chain worm operators have geopolitical motivations, they destroy systems in Israel and Iran while stealing data elsewhere.
5. IDE persistence means even after removing the compromised packages, the TeamPCP supply chain worm survives in VS Code and Claude Code configurations.
How to Protect Your Systems
The TeamPCP supply chain worm is active and spreading, here is what you need to do.
1. Check for affected packages. If you have any of the compromised versions listed above, assume your development environment is compromised, the TeamPCP supply chain worm may have stolen your credentials.
2. Rotate all credentials immediately. The TeamPCP supply chain worm steals npm tokens, GitHub tokens, cloud credentials, and cryptocurrency wallets, rotate everything that was on the compromised system.
3. Conduct an audit of the GitHub Actions workflows to identify any workflows that may be exfiltrating secrets; for example, TeamPCP's supply-chain worm injects workflows that serialize secrets and uploads them to the masscan API (api.masscan[.]cloud).
4. Review the extensions installed in Visual Studio Code and Claude Code; the TeamPCP supply-chain worm installs persistence hooks into the IDE used to code; inspect the IDE's configuration for unexpected scripts.
5. Review the OpenID Connect (OIDC) trusted publisher configurations (e.g., to use to enable signing on the OIDC project); ensure that the trust level applied to your GitHub (now) contains only limited scope on certain (to) branches or to the workflow file created, the TeamPCP supply-chain worm abuses the repository-level trust level (what that means is that OIDC can be misused to issue another trust).
6. Monitor for Session Protocol traffic. The TeamPCP supply chain worm exfiltrates data to filev2.getsession[.]org, block this domain if possible and investigate any outbound connections to it.
The Role of Trusted Publishing
The TeamPCP supply chain worm exposed a fundamental weakness in GitHub's trusted publishing model, OIDC tokens are powerful and repository-level trust is dangerous.
When a repository has OIDC trusted publisher configuration at the repository level rather than scoped to specific protected branches, any workflow run from any branch or fork can request publish tokens, and the TeamPCP supply chain worm exploited exactly this.
Organizations should scope OIDC trust to specific protected branches and specific workflow files, and they should require manual approval for workflow runs from untrusted forks.
Final Thoughts
The TeamPCP supply chain worm represents a new generation of supply chain attack, it does not steal npm tokens, it borrows them temporarily through OIDC, it does not publish unsigned packages, it publishes validly attested packages with SLSA provenance, it does not stay in one ecosystem, it spreads across npm and PyPI.
The TeamPCP supply chain worm operators are patient and skilled, they studied GitHub Actions, they understood OIDC token exchange, they crafted malicious packages that look legitimate even to provenance verification tools.
If you use TanStack, UiPath, Mistral AI, OpenSearch, or any of the affected packages, assume you have been exposed, check your systems, rotate your credentials, and review your own GitHub Actions security, because the next worm might not wait for you to read the advisory.
FAQ Section
What is the TeamPCP supply chain worm?
The TeamPCP supply chain worm is a self-propagating malware campaign that compromises npm and PyPI packages, it abuses GitHub OIDC tokens to publish malicious versions through legitimate build pipelines, and it has affected TanStack, UiPath, Mistral AI, OpenSearch, and Guardrails AI.
What is the mechanism for the worm's deployment onto additional packages?
The TeamPCP supply chain worm utilizes bypass_2fa: true publishable npm tokens to browse all packages published by an npm author, and the worm exploits GitHub OIDC tokens to obtain unique package-publish tokens from the author to create an unlimited number of malicious versions of any npm author's packages.
What is "CVE-2026-45321"?
CVE-2026-45321 is the identifier assigned for the TamStack supply chain compromise; it has a CVSS severity rating of 9.6 (Critical), it impacted 42 packages and 84 versions, and it describes how TeamPCP is abusing OIDC tokens to create malicious packages with valid SLSA provenance against npm authors.
Does the worm have destructive capabilities?
Yes, the TeamPCP supply chain worm includes a geofenced destructive branch in the malicious mistralai PyPI package, it has a 1-in-6 chance of executing rm -rf / when the infected system appears to be in Israel or Iran.
How can I verify if my packages are affected by the TeamPCP supply chain worm?
Check if you have any of the compromised versions listed in the article including TanStack packages, [email protected], [email protected], or any @opensearch-project versions, if you do, your environment is compromised and you should rotate all credentials immediately.
