TanStack npm Supply Chain Attack in 2026: CVE-2026-45321 (CVSS 9.6), Mini Shai-Hulud Worm & How to Protect Your CI/CDAttaque Supply Chain npm TanStack en 2026 : CVE-2026-45321 (CVSS 9.6), Ver Mini Shai-Hulud & Comment Protéger Votre CI/CD

At 19:20 UTC on May 11, 2026, an attacker published the first of 84 malicious npm package versions. By 19:26 UTC — six minutes later — the entire @tanstack/* ecosystem was compromised. CVE-2026-45321 (CVSS 9.6, Critical) is not just another supply chain incident: it is the first documented npm worm to produce cryptographically valid SLSA Build Level 3 provenance attestations, meaning every infected package appeared legitimate to automated security tools. The group behind the attack, TeamPCP, is the same threat actor responsible for the PyPI TeamPCP campaign and the Bitwarden CLI backdoor of April 2026.

À 19h20 UTC le 11 mai 2026, un attaquant a publié la première de 84 versions malveillantes de packages npm. À 19h26 UTC — six minutes plus tard — l’intégralité de l’écosystème @tanstack/* était compromis. CVE-2026-45321 (CVSS 9.6, Critique) n’est pas qu’un simple incident supply chain : c’est le premier ver npm documenté à produire des attestations de provenance SLSA Build Level 3 cryptographiquement valides, ce qui signifie que chaque package infecté semblait légitime aux outils de sécurité automatisés. Le groupe derrière l’attaque, TeamPCP, est le même acteur que celui responsable de la campagne PyPI TeamPCP et de la porte dérobée du Bitwarden CLI d’avril 2026.

What Is TanStack and Why Does It Matter?

Qu’est-ce que TanStack et pourquoi est-ce important ?

TanStack is a suite of open-source JavaScript libraries used by millions of React, Vue, Angular, and Solid developers worldwide. Its most popular packages include:

TanStack est une suite de bibliothèques JavaScript open-source utilisées par des millions de développeurs React, Vue, Angular et Solid dans le monde entier. Ses packages les plus populaires sont :

• @tanstack/react-query — 12 million weekly downloads, the de facto standard for async data fetching in React12 millions de téléchargements hebdomadaires, le standard de facto pour le data fetching asynchrone en React
• @tanstack/react-router — 12.7 million weekly downloads, a type-safe client-side router with a growing ecosystem12,7 millions de téléchargements hebdomadaires, un routeur client type-safe avec un écosystème en pleine croissance
• @tanstack/table — headless table UI library used extensively in dashboards and data-heavy applicationsbibliothèque UI headless pour les tableaux, très utilisée dans les dashboards et applications data-heavy
• @tanstack/virtual — virtualisation library for rendering large lists and grids efficientlybibliothèque de virtualisation pour rendre efficacement de grandes listes et grilles

With over 4 billion cumulative downloads and adoption at major companies across tech, finance, and healthcare, a compromise of the TanStack ecosystem reaches a significant portion of the global JavaScript supply chain. Installing a single affected version automatically installs the credential-stealing payload on your development machine or CI/CD runner.

Avec plus de 4 milliards de téléchargements cumulés et une adoption dans de grandes entreprises des secteurs de la tech, de la finance et de la santé, une compromission de l’écosystème TanStack touche une part significative de la chaîne d’approvisionnement JavaScript mondiale. L’installation d’une seule version affectée installe automatiquement le payload de vol de crédentiels sur votre machine de développement ou votre runner CI/CD.

The 3-Step Kill Chain: How the Attack Worked

La chaîne d’attaque en 3 étapes : comment l’attaque a fonctionné

TeamPCP chained three well-known but rarely combined vulnerability classes to publish malicious packages under the trusted @tanstack identity — without ever stealing a single npm token.

TeamPCP a enchané trois classes de vulnérabilités bien connues mais rarement combinées pour publier des packages malveillants sous l’identité de confiance @tanstack — sans jamais voler un seul token npm.

Step 1 — Fork & pull_request_target Abuse

Étape 1 — Fork & abus de pull_request_target

The attacker created a fork of the TanStack/router repository, renaming it to zblgg/configuration to avoid appearing in GitHub’s fork list. They then opened a pull request against the upstream repository. TanStack’s CI used the pull_request_target GitHub Actions event, which — unlike pull_request — runs in the context of the base branch and has access to repository secrets, even for PRs originating from forks.

L’attaquant a créé un fork du dépôt TanStack/router, le renommant en zblgg/configuration pour ne pas apparaître dans la liste des forks GitHub. Il a ensuite ouvert une pull request contre le dépôt upstream. Le CI de TanStack utilisait l’événement pull_request_target GitHub Actions, qui — contrairement à pull_request — s’exécute dans le contexte de la branche de base et a accès aux secrets du dépôt, même pour les PR issues de forks.

# DANGEROUS — runs attacker-controlled code with base-branch secrets
on:
  pull_request_target:
    types: [opened, synchronize]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # UNSAFE: checks out fork code
      - run: pnpm install  # Runs attacker's install scripts

Step 2 — GitHub Actions Cache Poisoning

Étape 2 — Empoisonnement du cache GitHub Actions

Once the malicious PR triggered the workflow, the attacker’s code ran inside a runner with base-branch permissions. The code poisoned the shared GitHub Actions cache (the pnpm store) with a malicious binary. Because GitHub Actions cache keys are shared across fork and base workflows, the next legitimate release workflow — running on refs/heads/main — picked up the poisoned cache and executed the attacker’s payload during the build step.

Une fois que la PR malveillante a déclenché le workflow, le code de l’attaquant s’est exécuté dans un runner avec les permissions de la branche de base. Le code a empoisonné le cache GitHub Actions partagé (le store pnpm) avec un binaire malveillant. Parce que les clés de cache GitHub Actions sont partagées entre les workflows fork et base, le prochain workflow de release légitime — s’exécutant sur refs/heads/main — a récupéré le cache empoisonné et exécuté le payload de l’attaquant pendant l’étape de build.

Step 3 — OIDC Token Extraction & Malicious Publish

Étape 3 — Extraction du token OIDC & publication malveillante

The malicious binary extracted a GitHub OIDC token directly from the runner’s process memory (/proc/<pid>/mem). TanStack’s postmortem confirmed the attacker reused the verbatim Python extraction script from the March 2025 tj-actions/changed-files compromise — including its attribution comment. Using this ephemeral OIDC token, the attacker exchanged it for a Fulcio signing certificate via Sigstore and published 84 malicious versions across 42 @tanstack/* packages. No npm tokens were compromised.

Le binaire malveillant a extrait un token OIDC GitHub directement depuis la mémoire du processus runner (/proc/<pid>/mem). Le postmortem de TanStack a confirmé que l’attaquant a réutilisé le script Python d’extraction verbatim de la compromission tj-actions/changed-files de mars 2025 — y compris son commentaire d’attribution. En utilisant ce token OIDC éphémère, l’attaquant l’a échangé contre un certificat de signature Fulcio via Sigstore et a publié 84 versions malveillantes sur 42 packages @tanstack/*. Aucun token npm n’a été compromis.

The Credential-Stealing Payload: What It Does

Le Payload Voleur de Crédentiels : ce qu’il fait

The payload injected into every compromised @tanstack/* package performs a systematic sweep of developer environments and CI/CD pipelines. It reads from over 100 hardcoded file paths and environment variables, targeting:

Le payload injecté dans chaque package @tanstack/* compromis effectue un balayage systématique des environnements de développement et des pipelines CI/CD. Il lit plus de 100 chemins de fichiers codés en dur et variables d’environnement, ciblant :

• Cloud credentials: AWS ~/.aws/credentials, GCP application_default_credentials.json, Azure ~/.azure/, GOOGLE_APPLICATION_CREDENTIALSCrédentiels cloud : AWS ~/.aws/credentials, GCP application_default_credentials.json, Azure ~/.azure/, GOOGLE_APPLICATION_CREDENTIALS
• SSH keys: ~/.ssh/id_rsa, id_ed25519, known_hosts, all private key filesClés SSH : ~/.ssh/id_rsa, id_ed25519, known_hosts, tous les fichiers de clés privées
• Environment files: .env, .env.local, .env.production containing API keys and database credentialsFichiers d’environnement : .env, .env.local, .env.production contenant des clés API et crédentiels de base de données
• GitHub tokens: GITHUB_TOKEN, GH_TOKEN, ~/.config/gh/hosts.ymlTokens GitHub : GITHUB_TOKEN, GH_TOKEN, ~/.config/gh/hosts.yml
• Crypto wallets: browser extension storage, ~/.ethereum/, hardware wallet seed phrase filesPortefeuilles crypto : stockage des extensions navigateur, ~/.ethereum/, fichiers de phrases de démarrage des wallets matériels
• VPN and messaging: WireGuard configs, Slack tokens, Discord tokens from browser storageVPN et messagerie : configs WireGuard, tokens Slack, tokens Discord depuis le stockage navigateur
• Shell history: ~/.bash_history, ~/.zsh_history — extracting credentials typed directly in the terminalHistorique shell : ~/.bash_history, ~/.zsh_history — extraction des crédentiels tapés directement dans le terminal

On developer machines, the payload installs a persistent gh-token-monitor daemon — a macOS LaunchAgent or Linux systemd service — that polls GitHub every 60 seconds to harvest freshly generated tokens. Notably, the payload deliberately skips tokens explicitly named GITHUB_TOKEN to avoid triggering GitHub’s built-in secret-scanning detection on exfiltrated data.

Sur les machines des développeurs, le payload installe un dæmon persistant gh-token-monitor — un LaunchAgent macOS ou un service systemd Linux — qui interroge GitHub toutes les 60 secondes pour récupérer les tokens fraichement générés. Notamment, le payload ignore délibérément les tokens explicitement nommés GITHUB_TOKEN pour éviter de déclencher la détection de secrets intégrée de GitHub sur les données exfiltrées.

The SLSA Provenance Bypass: Why “Signed” Doesn’t Mean “Safe”

Le Contournement de la Provenance SLSA : pourquoi « signé » ne veut pas dire « sûr »

This is the most technically significant aspect of CVE-2026-45321. Every compromised @tanstack/* package carried a valid SLSA Build Level 3 provenance attestation — the highest supply-chain integrity guarantee in widespread use. The attestations were generated by the Sigstore stack (Fulcio certificate authority + Rekor transparency log) and are technically correct: they accurately state that the packages were built by release.yml running on refs/heads/main in the TanStack/router repository.

C’est l’aspect techniquement le plus significatif de CVE-2026-45321. Chaque package @tanstack/* compromis portait une attestation de provenance SLSA Build Level 3 valide — la garantie d’intégrité de la supply chain la plus élevée en usage généralisé. Les attestations ont été générées par la pile Sigstore (autorité de certification Fulcio + journal de transparence Rekor) et sont techniquement correctes : elles affirment avec exactitude que les packages ont été construits par release.yml s’exécutant sur refs/heads/main dans le dépôt TanStack/router.

The fundamental limitation exposed here is this: SLSA provenance verifies the build pipeline, not the build inputs. Because the attacker poisoned the pipeline’s cache — the input to the build — the output was malicious even though the build process itself was technically unmodified. Sigstore’s Fulcio correctly issued a certificate for the build. The Rekor log correctly recorded it. Every verifier that checked the attestation would have seen a valid, trusted signature.

La limitation fondamentale exposée ici est la suivante : la provenance SLSA vérifie le pipeline de build, pas les entrées du build. Parce que l’attaquant a empoisonné le cache du pipeline — l’entrée du build — la sortie était malveillante même si le processus de build lui-même était techniquement non modifié. Le Fulcio de Sigstore a correctement émis un certificat pour le build. Le journal Rekor l’a correctement enregistré. Tout vérificateur qui aurait contrôlé l’attestation aurait vu une signature valide et de confiance.

Who Else Was Hit: TeamPCP’s Expanding Campaign

Qui d’autre a été touché : la campagne croissante de TeamPCP

The TanStack compromise was not an isolated incident. Within hours of the initial attack, the same Mini Shai-Hulud worm spread to infect packages from additional organizations, exploiting similar pull_request_target misconfigurations across the JavaScript and Python ecosystems:

La compromission de TanStack n’était pas un incident isolé. Dans les heures suivant l’attaque initiale, le même ver Mini Shai-Hulud s’est propagé pour infecter des packages d’organisations supplémentaires, exploitant des mauvaises configurations pull_request_target similaires dans les écosystèmes JavaScript et Python :

• @uipath/* — 65 packages from UiPath, the RPA automation platform with millions of enterprise users65 packages d’UiPath, la plateforme d’automatisation RPA avec des millions d’utilisateurs en entreprise
• @mistralai/mistralai — the official Mistral AI SDK plus both cloud variants (-azure and -gcp)le SDK officiel Mistral AI ainsi que les deux variantes cloud (-azure et -gcp)
• @opensearch-project/opensearch — the official OpenSearch JavaScript client used in enterprise search pipelinesle client JavaScript officiel OpenSearch utilisé dans les pipelines de recherche en entreprise
• guardrails-ai — a widely-used LLM safety framework, spreading the attack into AI application supply chainsun framework de sécurité LLM largement utilisé, propageant l’attaque dans les chaînes d’approvisionnement d’applications IA
• squawk — a popular SQL linter for PostgreSQL migrationsun linter SQL populaire pour les migrations PostgreSQL

This is TeamPCP’s third major campaign in 2026 alone, following the March 2026 PyPI attack targeting LiteLLM (95M downloads/month) and the April 2026 Bitwarden CLI backdoor (compromised via GitHub Actions in 93 minutes). The group demonstrates consistent expertise in CI/CD pipeline exploitation and a growing reach across multiple package registries.

C’est la troisième grande campagne de TeamPCP en 2026 seulement, après l’attaque PyPI de mars 2026 ciblant LiteLLM (95M téléchargements/mois) et la porte dérobée Bitwarden CLI d’avril 2026 (compromise via GitHub Actions en 93 minutes). Le groupe démontre une expertise cohérente dans l’exploitation des pipelines CI/CD et une portée croissante sur plusieurs registres de packages.

How to Protect Your Projects: 6-Point Hardening Checklist

Comment protéger vos projets : liste de contrôle de durcissement en 6 points

1. Audit Your Current TanStack Versions Immediately

1. Auditez vos versions TanStack actuellement installées immédiatement

Check whether your lockfile references any of the affected versions. The malicious versions were published on May 11, 2026 — any version with a resolved timestamp in that window is suspect. Run:

Vérifiez si votre lockfile référence des versions affectées. Les versions malveillantes ont été publiées le 11 mai 2026 — toute version avec un timestamp resolved dans cette fenêtre est suspecte. Exécutez :

# List all @tanstack packages and versions in your lockfile
cat package-lock.json | jq '.packages | to_entries[] | select(.key | startswith("node_modules/@tanstack")) | {package: .key, version: .value.version}'

# npm audit — check for CVE-2026-45321
npm audit --json | jq '.vulnerabilities | to_entries[] | select(.value.nodes[] | startswith("node_modules/@tanstack"))'

# Or with npx
npx npm-check-updates "@tanstack/*"

2. Remove pull_request_target or Isolate It Completely

2. Supprimer pull_request_target ou l’isoler complètement

If you maintain open-source repositories, audit every workflow for pull_request_target. Replace it with pull_request wherever secrets are not needed for fork PR testing. If pull_request_target is genuinely required, never check out the fork’s code in the same job that has access to secrets.

Si vous maintenez des dépôts open-source, auditez chaque workflow pour pull_request_target. Remplacez-le par pull_request partout où les secrets ne sont pas nécessaires pour tester les PR de forks. Si pull_request_target est réellement requis, ne jamais check out le code du fork dans le même job qui a accès aux secrets.

on:
  pull_request_target:

jobs:
  # Job 1: run tests WITHOUT secrets, checking out fork code
  test:
    runs-on: ubuntu-latest
    permissions:
      contents: read  # minimal permissions
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: npm test  # no secrets available here

  # Job 2: publish only after test passes, using base code only
  publish:
    needs: test
    runs-on: ubuntu-latest
    if: github.event_name != 'pull_request_target'  # never publish from fork PRs
    steps:
      - uses: actions/checkout@v4  # no ref override — always base branch
      - run: npm publish
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

3. Disable GitHub Actions Cache for Untrusted Inputs

3. Désactiver le cache GitHub Actions pour les entrées non fiables

GitHub Actions cache keys are shared between fork and base branch workflows on the same repository. A cache entry created by a fork PR workflow can be read by the base branch’s release workflow. As a mitigation: use separate cache key prefixes for PR workflows vs release workflows, or disable caching entirely in pull_request_target jobs.

Les clés de cache GitHub Actions sont partagées entre les workflows fork et la branche de base sur le même dépôt. Une entrée de cache créée par un workflow de PR de fork peut être lue par le workflow de release de la branche de base. En guise d’atténuation : utilisez des préfixes de clés de cache séparés pour les workflows PR vs les workflows de release, ou désactivez entièrement le cache dans les jobs pull_request_target.

4. Pin All GitHub Actions to Full Commit SHAs

4. Ancrer toutes les GitHub Actions à des SHAs de commit complets

Pinning actions to a full 40-character SHA ensures that even if an action’s tag is moved (e.g., v4 force-pushed to a malicious commit), your workflow remains protected. GitHub’s 2026 security roadmap includes SHA pinning enforcement — start now.

Ancrer les actions à un SHA complet de 40 caractères garantit que même si le tag d’une action est déplacé (ex. v4 force-pushé vers un commit malveillant), votre workflow reste protégé. La feuille de route sécurité GitHub Actions 2026 inclut l’enforcement du pinning SHA — commencez maintenant.

# BAD — tag can be moved to malicious commit
- uses: actions/checkout@v4

# GOOD — immutable SHA
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2

5. Restrict OIDC Token Permissions

5. Restreindre les permissions du token OIDC

Apply the principle of least privilege to all workflows. Tokens should have the minimum permissions required for the job. For release workflows that publish to npm, the token should only have id-token: write and contents: read. Setting permissions: {} at the top level forces explicit opt-in for every permission.

Appliquez le principe du moindre privilège à tous les workflows. Les tokens doivent avoir les permissions minimales requises pour le job. Pour les workflows de release qui publient sur npm, le token ne doit avoir que id-token: write et contents: read. Définir permissions: {} au niveau supérieur force un opt-in explicite pour chaque permission.

6. Monitor Your Dependency Lockfiles for Unexpected Changes

6. Surveiller vos lockfiles de dépendances pour les changements inattendus

One of the most effective early warning signals for a supply chain attack is an unexpected change in your lockfile — a version bump you didn’t request, a new resolved URL, a new integrity hash. Automated lockfile monitoring catches these anomalies before they reach production.

L’un des signaux d’alarme les plus efficaces pour une attaque supply chain est un changement inattendu dans votre lockfile — une mise à jour de version que vous n’avez pas demandée, une nouvelle URL résolue, un nouveau hash d’intégrité. La surveillance automatisée des lockfiles détecte ces anomalies avant qu’elles n’atteignent la production.

What to Do Right Now If You Use TanStack

Que faire maintenant si vous utilisez TanStack

If your project depends on any @tanstack/* package, take these steps immediately:

Si votre projet dépend d’un package @tanstack/*, prenez ces mesures immédiatement :

1. Update all @tanstack/* packages to the latest patched versions (any version published after May 11, 2026 after the incident was resolved is safe)Mettre à jour tous les packages @tanstack/* vers les dernières versions patched (toute version publiée après la résolution de l’incident le 11 mai 2026 est sûre)
2. Rotate all secrets that may have been present in your CI/CD environment on May 11, 2026 — especially npm tokens, cloud provider credentials, SSH keys, and GitHub PATsRotation de tous les secrets qui auraient pu être présents dans votre environnement CI/CD le 11 mai 2026 — en particulier les tokens npm, les crédentiels des fournisseurs cloud, les clés SSH et les PATs GitHub
3. Check for the persistent daemon: on Linux run systemctl status gh-token-monitor, on macOS check launchctl list | grep gh-tokenVérifier la présence du dæmon persistant : sur Linux exécutez systemctl status gh-token-monitor, sur macOS vérifiez launchctl list | grep gh-token
4. Run npm audit and cross-reference with the full list of affected packages published by StepSecurity, Snyk, and WizExécuter npm audit et recouper avec la liste complète des packages affectés publiée par StepSecurity, Snyk et Wiz
5. Delete the node_modules directory and reinstall from scratch using npm ci (which enforces lockfile integrity and skips cache) if you suspect exposureSupprimer le répertoire node_modules et réinstaller depuis zéro en utilisant npm ci (qui applique l’intégrité du lockfile et ignore le cache) si vous suspectez une exposition

Frequently Asked Questions

Questions fréquentes