Photo de Michael Geigersur Unsplash
<p>Si vous développez des applications basées sur l&rsquo;intelligence artificielle, si vous utilisez des bibliothèques Python ou JavaScript pour accéder à des APIs de modèles comme celles d&rsquo;OpenAI, Anthropic ou Mistral, ou si vous travaillez avec des outils comme Claude Code ou VS Code pour coder au quotidien, alors cet article vous concerne directement. Pas de façon abstraite ou théorique. De façon très concrète, avec un risque que vous avez peut-être déjà subi sans le savoir.</p>
<p>Depuis mars 2026, un groupe de pirates informatiques répondant au nom de TeamPCP mène l&rsquo;une des campagnes d&rsquo;attaque les plus sophistiquées jamais documentées contre les développeurs de logiciels IA. Baptisée « Mini Shai-Hulud » en référence aux immenses vers des sables du roman de science-fiction Dune, cette opération a contaminé plus de 400 versions de packages logiciels sur les deux plus grands dépôts de code au monde : npm (pour JavaScript) et PyPI (pour Python). Le bilan provisoire : 518 millions de téléchargements potentiellement affectés.</p>
<p>Mais ce qui rend cette attaque vraiment singulière, ce n&rsquo;est pas son ampleur. C&rsquo;est sa cible. Pour la première fois dans l&rsquo;histoire documentée de la cybersécurité, des pirates ont délibérément choisi de s&rsquo;en prendre aux outils spécifiques utilisés par les développeurs IA, les briques logicielles qui connectent le code aux modèles d&rsquo;intelligence artificielle. Et ils ont aussi découvert une technique inédite : se cacher à l&rsquo;intérieur des fichiers de configuration des assistants de codage IA, pour survivre même après que l&rsquo;infection initiale a été nettoyée.</p>
<h2>Première étape : comprendre la chaîne d&rsquo;approvisionnement logicielle</h2>
<p>Avant d&rsquo;aller plus loin, il faut expliquer un concept fondamental : la supply chain logicielle, ou chaîne d&rsquo;approvisionnement du logiciel. Ce terme un peu barbeux désigne tout simplement l&rsquo;ensemble des outils, bibliothèques et dépendances externes qu&rsquo;un développeur utilise pour construire son application.</p>
<p>Quand vous créez un programme en Python, vous ne repartez pas de zéro. Vous utilisez des packages déjà écrits par d&rsquo;autres, que vous téléchargez depuis PyPI. Vous avez besoin de faire des requêtes HTTP ? Vous installez la bibliothèque requests. Vous voulez accéder à l&rsquo;API d&rsquo;OpenAI ? Vous installez openai. Vous voulez router vos appels vers plusieurs modèles IA différents ? Vous installez LiteLLM. Ces packages sont écrits et maintenus par des développeurs, souvent bénévoles, que vous ne connaissez pas. Et vous leur faites confiance implicitement, parce que tout le monde les utilise.</p>
<p>Une attaque supply chain, c&rsquo;est exactement ça : plutôt que d&rsquo;attaquer votre application directement, ce qui serait difficile, les pirates s&rsquo;infiltrent dans l&rsquo;un de ces packages de confiance. Quand vous l&rsquo;installez ou le mettez à jour, vous intégrez sans le savoir du code malveillant dans votre environnement de travail. C&rsquo;est comme si un fournisseur de pièces automobiles glissait un traceur GPS dans les pièces qu&rsquo;il vous livre, sans que personne dans l&rsquo;usine ne remarque quoi que ce soit.</p>
<h2>Pourquoi les développeurs IA sont la cible idéale</h2>
<p>TeamPCP n&rsquo;a pas choisi ses victimes au hasard. Chaque package compromis occupe une position stratégique dans la chaîne de développement IA. Examinons les principales victimes documentées :</p>
<ul>
<li>LiteLLM (bibliothèque Python)</li>
</ul>
<p>LiteLLM est une bibliothèque qui sert de « routeur universel » pour les APIs de modèles IA. Elle permet aux développeurs d&rsquo;écrire leur code une seule fois et de l&rsquo;utiliser indifféremment avec OpenAI, Anthropic, Mistral, Google Gemini, ou des dizaines d&rsquo;autres fournisseurs. Conséquence directe : toutes les clés API de ces services transitent par LiteLLM. Les versions 1.82.7 et 1.82.8 publiées sur PyPI contenaient un voleur d&rsquo;identifiants multi-étages qui s&rsquo;exécutait avant même le démarrage de l&rsquo;application.</p>
<ul>
<li>Mistral AI SDK (bibliothèque Python/npm)</li>
</ul>
<p>Le kit de développement officiel pour accéder aux modèles du fournisseur d&rsquo;IA français Mistral. Des millions de développeurs l&rsquo;utilisent pour intégrer des capacités d&rsquo;IA dans leurs applications. Sa compromission donne aux attaquants un accès direct aux clés API Mistral des développeurs infectés.</p>
<ul>
<li>Guardrails AI (bibliothèque Python)</li>
</ul>
<p>Une bibliothèque qui sert à valider et filtrer les sorties des modèles IA. En gros, c&rsquo;est le « garde-fou » qui vérifie que votre modèle ne dit pas n&rsquo;importe quoi. Sa position dans le pipeline IA lui donne accès aux réponses des modèles et aux configurations de sécurité de l&rsquo;application.</p>
<ul>
<li>TanStack (bibliothèque JavaScript)</li>
</ul>
<p>L&rsquo;une des bibliothèques JavaScript les plus populaires pour la gestion d&rsquo;état et de données dans les applications web. Plus de 160 packages du même écosystème ont été compromis dans une seule vague le 11 mai 2026.</p>
<ul>
<li>Microsoft DurableTask Python (bibliothèque Python)</li>
</ul>
<p>Un client Python utilisé dans les workflows d&rsquo;automatisation d&rsquo;entreprise, notamment ceux qui intègrent des composants IA.</p>
<p>Ce qui unifie ces choix, c&rsquo;est une connaissance précise du paysage du développement IA. Un développeur qui travaille sur une application d&rsquo;IA détient simultanément des clés API pour des services de modèles en cloud (qui peuvent coûter très cher à la consommation), des accès à des instances GPU, des identifiants pour des bases de données vectorielles, et des tokens ou jetons pour ses pipelines CI/CD. Pour un attaquant, un seul développeur IA compromis peut valoir bien plus qu&rsquo;une cible classique.</p>
<h2>Comment l&rsquo;attaque fonctionne techniquement</h2>
<p>Voici la machinerie de l&rsquo;attaque, expliquée sans jargon trop technique de ce que j&rsquo;ai compris (les experts pourront débattre ou apporter des correction en commentaire). Elle se déroule en trois grandes phases.</p>
<h3>Phase 1 : S&rsquo;introduire dans le pipeline de publication</h3>
<p>TeamPCP a d&rsquo;abord ciblé des dépôts GitHub de projets populaires qui utilisaient un mécanisme appelé pull_request_target dans leurs automatisations de flux de travail. Sans entrer dans les détails techniques, imaginez que c&rsquo;est une « porte de service » qui, si elle est mal configurée, permet à quelqu&rsquo;un d&rsquo;extérieur de déclencher des actions automatiques dans le dépôt, y compris publier de nouvelles versions de packages.</p>
<p>Les pirates ont soumis une modification de code apparemment anodine (une « pull request »). Invisible à l&rsquo;oeil humain, elle contenait un poison glissé dans le cache de dépendances du projet. Huit heures plus tard, quand un vrai mainteneur du projet a fusionné une modification légitime, le système automatisé a utilisé le cache empoisonné&#8230; et publié une version malveillante du package sur npm ou PyPI, signée avec les propres identifiants du projet.</p>
<h3>Phase 2 : Voler des mots de passe de façon indétectable</h3>
<p>Le code malveillant inséré dans les packages agit comme un aspirateur à secrets. Techniquement, il lit directement la mémoire du processus responsable des automatisations GitHub (GitHub Actions Runner). C&rsquo;est là que se trouvent les tokens OIDC, des jetons d&rsquo;accès temporaires normalement masqués dans les journaux d&rsquo;activité. En les extrayant directement de la mémoire, TeamPCP contourne les protections habituelles.</p>
<p>Avec ces jetons, une prouesse supplémentaire devient possible : les pirates génèrent des certificats numériques qui ressemblent à des preuves d&rsquo;authenticité parfaitement valides, ce qu&rsquo;on appelle des attestations SLSA de niveau 3. C&rsquo;est l&rsquo;équivalent de fabriquer de faux tampons officiels tellement parfaits que les douanes les acceptent sans sourciller. Les outils de vérification d&rsquo;intégrité des packages ont donné le feu vert à ces packages empoisonnés, convaincus qu&rsquo;ils avaient été construits proprement.</p>
<p>La charge utile volée est impressionnante dans sa portée : le logiciel malveillant est programmé pour siphonner les identifiants stockés dans plus de 100 emplacements différents sur l&rsquo;ordinateur infecté. Cela comprend les clés AWS, Azure et Google Cloud, les tokens GitHub, les tokens npm, les configurations Kubernetes, les coffres HashiCorp Vault, les données 1Password, et spécifiquement les fichiers de configuration des outils IA.</p>
<h3>Phase 3 : La nouveauté la plus inquiétante, se terrer dans vos outils IA</h3>
<p>C&rsquo;est ici que l&rsquo;attaque franchit une frontière véritablement inédite dans l&rsquo;histoire de la cybersécurité. TeamPCP a eu l&rsquo;idée de modifier deux fichiers de configuration que les assistants de codage IA lisent automatiquement à chaque ouverture de projet :</p>
<ul>
<li>.claude/settings.json : le fichier de configuration de Claude Code, l&rsquo;assistant IA de codage d&rsquo;Anthropic</li>
<li>.vscode/tasks.json : le fichier de tâches de VS Code, que l&rsquo;éditeur exécute automatiquement à l&rsquo;ouverture d&rsquo;un dossier</li>
</ul>
<p>En ajoutant un hook de type « SessionStart » dans le premier, et une tâche automatique dans le second, le malware s&rsquo;assure de se ré-exécuter à chaque fois qu&rsquo;un développeur ouvre son projet. Et ce, même si le package infecté a été supprimé, même si le fichier de dépendances a été nettoyé, même si un scan antivirus a fait son travail.</p>
<p>â ï¸ C&rsquo;est la première attaque supply chain documentée à utiliser un assistant de codage IA comme vecteur de persistance. Claude Code et VS Code fonctionnent avec les mêmes droits d&rsquo;accès que le développeur lui-même : ils peuvent lire des fichiers, exécuter des commandes, accéder à tous les secrets présents dans l&rsquo;environnement. Un hook malveillant dans leur configuration, c&rsquo;est un accès permanent et discret à tout ce que vous faites.</p>
<h2>L&rsquo;ampleur des dégâts en chiffres</h2>
<p> ;</p>
<table width="0">
<thead>
<tr>
<td width="240"><strong>Indicateur</strong></td>
<td width="320"><strong>Chiffre documenté</strong></td>
</tr>
</thead>
<tbody>
<tr>
<td width="240">Packages compromis</td>
<td width="320">170+ packages distincts (npm + PyPI)</td>
</tr>
<tr>
<td width="240">Versions malveillantes publiées</td>
<td width="320">400+ versions</td>
</tr>
<tr>
<td width="240">Téléchargements potentiellement affectés</td>
<td width="320">518 millions cumulés</td>
</tr>
<tr>
<td width="240">Durée de la campagne active</td>
<td width="320">Mars 2026 → aujourd&rsquo;hui (en cours)</td>
</tr>
<tr>
<td width="240">Victimes confirmées notables</td>
<td width="320">2 appareils d&#8217;employés OpenAI (via TanStack)</td>
</tr>
<tr>
<td width="240">Vitesse de la plus grande vague</td>
<td width="320">400 versions publiées en ~5 heures (11 mai 2026)</td>
</tr>
<tr>
<td width="240">Emplacements de secrets ciblés</td>
<td width="320">Plus de 100 chemins distincts sur un ordinateur infecté</td>
</tr>
</tbody>
</table>
<p>La vague du 11 mai 2026 mérite une mention particulière. En l&rsquo;espace de cinq heures environ, TeamPCP a publié plus de 400 versions de packages malveillants sur 172 projets distincts. Le rythme de publication a dépassé la capacité de réaction des registres npm et PyPI. Avant que les équipes de sécurité puissent analyser et retirer les packages incriminés, des millions de développeurs avaient déjà potentiellement téléchargé les versions empoisonnées via leurs mises à jour automatiques.</p>
<h2>La bombe à retardement : le code source publié en open source</h2>
<p>Si tout ce qui précède est déjà inquiétant, la décision de TeamPCP annoncée vers le 15 mai 2026 l&rsquo;est encore plus. Le groupe a rendu public le code source complet du ver Shai-Hulud, le présentant comme une « publication open source ».</p>
<p>En termes simples : les techniques utilisées (le vol de tokens OIDC depuis la mémoire, la falsification d&rsquo;attestations SLSA, la persistance via les configs d&rsquo;assistants IA) ne sont plus le secret exclusif d&rsquo;un groupe sophistiqué. N&rsquo;importe qui, avec un niveau technique modeste, peut désormais adapter ces outils. Ce qui était une arme de haute technologie est devenu un kit disponible sur étagère.</p>
<p>Les experts en sécurité s&rsquo;attendent à voir émerger des copies et des variantes de cette attaque dans les mois qui viennent, portées par des acteurs bien moins compétents que TeamPCP mais tout aussi capables de nuire.</p>
<h2>Une particularité glaçante : un malware qui détruit selon votre localisation</h2>
<p>La charge malveillante contient une logique géographique. Sur les machines dont les paramètres de langue ou de région suggèrent une origine iranienne ou israélienne, le malware intègre une probabilité d&rsquo;une chance sur six d&rsquo;exécuter une commande de destruction récursive du système de fichiers. C&rsquo;est-à-dire effacer tous vos fichiers.</p>
<p>Par contraste, les machines configurées en environnement russophone sont délibérément épargnées. Ce type de comportement est caractéristique, dans le vocabulaire du renseignement cyber, d&rsquo;acteurs qui cherchent à éviter des poursuites judiciaires dans leur pays d&rsquo;origine. Cela oriente les soupçons vers des acteurs opérant depuis des pays russophones, même si aucune attribution officielle n&rsquo;a été publiée à ce jour.</p>
<h2>Que faire si vous êtes développeur IA ?</h2>
<p>Voici les mesures à prendre, classées par urgence. Si vous utilisez l&rsquo;une des bibliothèques mentionnées dans cet article, lisez ceci attentivement.</p>
<h3>ð¨ Actions immédiates</h3>
<ul>
<li>Vérifiez si vous avez installé l&rsquo;une des versions compromises.</li>
</ul>
<p>Packages à vérifier en priorité : litellm (versions 1.82.7-1.82.8), mistralai, guardrails-ai, microsoft-durabletask-python, tout package @tanstack/*. Utilisez pip show litellm ou npm list pour voir quelle version vous avez installée.</p>
<ul>
<li>Inspectez vos fichiers de configuration IA immédiatement.</li>
</ul>
<p>Ouvrez « .claude/settings.json » dans vos dépôts et votre répertoire utilisateur. Vérifiez l&rsquo;absence de toute entrée SessionStart que vous n&rsquo;avez pas créée vous-même. Faites la même chose avec « .vscode/tasks.json » : tout bloc « runOn: folderOpen » non attendu est suspect.</p>
<ul>
<li>Révoquez et régénérez toutes vos clés API si vous avez un doute.</li>
</ul>
<p>Cela comprend : vos tokens GitHub, vos clés AWS/Azure/GCP, vos API keys pour OpenAI, Anthropic, Mistral, vos tokens npm. Faites-le avant de reprendre votre travail normal.</p>
<p>ð Conseil : Le <a href="https://isc.sans.edu/diary/32994">SANS Internet Storm Center</a> maintient une liste actualisée des versions malveillantes connues dans leur journal de suivi TeamPCP. Consultez-la pour savoir précisément quelles versions sont concernées.</p>
<h3>ð¡ï¸ Mesures préventives à mettre en place</h3>
<ul>
<li>Utilisez des fichiers de verrouillage avec hachages de contenu (package-lock.json, requirements.txt avec hashes). Cela empêche les mises à jour automatiques vers une version non vérifiée.</li>
<li>Activez les GitHub Secret Scanning alerts sur tous vos dépôts. GitHub peut détecter certains fuites d&rsquo;identifiants par inadvertance.</li>
<li>Ne stockez jamais vos clés API en clair dans votre code ou vos fichiers de configuration. Utilisez des variables d&rsquo;environnement ou un gestionnaire de secrets comme HashiCorp Vault ou AWS Secrets Manager.</li>
<li>Auditez régulièrement vos dépendances avec des outils comme pip-audit (Python), npm audit (JavaScript), ou des solutions professionnelles comme Snyk ou Sonatype.</li>
<li>Vérifiez vos workflows GitHub Actions pour la mauvaise configuration pull_request_target. Si vous en utilisez, assurez-vous que les caches sont isolés entre les forks et le dépôt principal.</li>
</ul>
<h3>ð¢ Pour les équipes et entreprises</h3>
<ul>
<li>Intégrez les répertoires de configuration des assistants IA (.claude/, .vscode/) dans le périmètre de vos outils de détection d&rsquo;intégrité des fichiers (FIM). Ces chemins sont désormais des surfaces d&rsquo;attaque à surveiller au même titre que les fichiers CI/CD.</li>
<li>Mettez en place une surveillance multi-registres. Une attaque qui commence sur npm peut se propager à PyPI en moins de 36 heures, votre monitoring doit couvrir tous les écosystèmes utilisés par vos équipes.</li>
<li>Intégrez les techniques de Mini Shai-Hulud dans vos exercices de simulation d&rsquo;attaque (red team). Mieux vaut tester votre capacité de détection maintenant, avant que ces techniques n&rsquo;apparaissent dans des kits d&rsquo;attaque grand public.</li>
</ul>
<h2>La leçon de fond : l&rsquo;IA crée de nouvelles surfaces d&rsquo;attaque invisibles</h2>
<p>Au-delà des mesures techniques immédiates, Mini Shai-Hulud révèle une vérité structurelle sur le développement IA que la communauté commence à peine à appréhender. Les fonctionnalités qui rendent les assistants de codage IA si productifs, leur accès profond au système de fichiers, leur chargement automatique de configurations, leur capacité à exécuter des commandes, sont exactement les propriétés qui en font des vecteurs d&rsquo;attaque attractifs.</p>
<p>C&rsquo;est un paradoxe inhérent à l&rsquo;intégration de l&rsquo;IA dans les flux de travail en développement. Vous donnez à votre assistant IA les mêmes droits que vous-même, parce que c&rsquo;est la seule façon de le rendre vraiment utile. Mais ce faisant, vous créez un point d&rsquo;entrée potentiel que les modèles de sécurité traditionnels n&rsquo;ont pas été conçus pour surveiller.</p>
<p>La Cloud Security Alliance le formule clairement dans son rapport : les organisations qui déploient des assistants IA dans leurs flux de travail en développement doivent définir des frontières de confiance explicites pour ces agents, traiter leurs fichiers de configuration avec le même niveau de rigueur que leurs définitions de pipeline CI/CD, et inclure les répertoires de configuration IA dans le périmètre de détection des endpoints. Ce n&rsquo;est plus une recommandation optionnelle, c&rsquo;est une nécessité opérationnelle.</p>
<h2>Bienvenue dans l&rsquo;ère des cyberattaques ciblant l&rsquo;IA</h2>
<p>Mini Shai-Hulud n&rsquo;est pas une anecdote de cybersécurité. C&rsquo;est un signal de basculement. Pour la première fois, des attaquants ont construit une campagne entière autour de la spécificité des environnements de développement IA : leurs outils, leurs bibliothèques, leurs assistants, leurs identifiants. Et ils ont trouvé une façon inédite de persister à l&rsquo;intérieur de ces environnements, en se logeant dans les fichiers de configuration des assistants que vous consultez des dizaines de fois par jour.</p>
<p>La bonne nouvelle ? Les mesures de protection existent et sont largement accessibles. Auditer ses dépendances, verrouiller ses versions, inspecter ses fichiers de configuration, révoquer et régénérer ses clés API régulièrement, aucune de ces pratiques ne requiert un budget de sécurité monumental. Ce qu&rsquo;elles requièrent, c&rsquo;est de la vigilance et de la discipline.</p>
<p>Dans un monde où l&rsquo;IA s&rsquo;intègre de plus en plus profondément dans les flux de travail en développement, la sécurité de la chaîne d&rsquo;approvisionnement logicielle n&rsquo;est plus seulement une préoccupation d&rsquo;infrastructure. C&rsquo;est une question de confiance fondamentale dans les outils que vous utilisez pour construire l&rsquo;avenir. Et cette confiance, comme TeamPCP vient de le démontrer de façon éclatante, ne se présuppose plus. Elle se vérifie.</p>
<p style="text-align: right;">Source : <a href="https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/05/CSA_research_note_shai_hulud_supply_chain_ai_pipeline_20260521-csa-styled.pdf">CSA</a></p>

En janvier 2026, une ingénieure chez Google a posté quelque chose d'assez stupéfiant sur les…
Une matinée qui va rester dans les livres d'histoire Le 25 mai 2026. Il est…
Imaginez que vous vous réveillez un matin, que vous allumez votre ordinateur, et que vous…