Vos développeurs font confiance à leurs outils. Cette confiance est exploitée.
Le 24 mars 2026, des développeurs créant des applications d’IA avec LiteLLM – un package Python avec 95 millions de téléchargements mensuels – ont installé sans le savoir un code malveillant. Un groupe d’acteurs menaçants connu sous le nom de TeamPCP avait compromis le pipeline de distribution PyPI et poussé les versions malveillantes 1.82.7 et 1.82.8 vers l’index du package. La charge utile était subtile : un fichier .pth, un mécanisme Python peu connu qui exécute automatiquement le code à chaque démarrage de l’interpréteur. Si vous installiez l’une ou l’autre des versions compromises, le code malveillant s’exécutait silencieusement : aucune importation explicite n’était nécessaire.
Ce n’est plus l’exception. C’est le modèle.
Que se passe-t-il réellement
ReversingLabs rapporte que les packages open source malveillants ont augmenté de 73 % en 2026. L’attaque LiteLLM faisait partie d’une campagne plus large de TeamPCP qui a systématiquement compromis des outils de sécurité open source largement fiables, notamment Trivy d’Aqua Security et KICS de Checkmarx, avant de passer aux bibliothèques d’infrastructure d’IA hébergées sur PyPI.
La chaîne d’attaque de LiteLLM a suivi une séquence désormais familière. TeamPCP a obtenu les informations d’identification de publication PyPI du responsable, a diffusé des versions malveillantes pratiquement impossibles à distinguer du package officiel et a intégré une charge utile en plusieurs étapes conçue pour récolter des secrets de grande valeur : jetons AWS, GCP et Azure, clés SSH et informations d’identification de compte cloud. Selon Zscaler ThreatLabz, les colis empoisonnés étaient disponibles environ trois heures avant la quarantaine. Trois heures ont suffi pour atteindre des dizaines de milliers d’environnements d’entreprise.
Et cela ne s’est pas arrêté avec LiteLLM. Fin avril 2026, les versions 2.6.2 et 2.6.3 de PyTorch Lightning contenaient des logiciels malveillants de vol d’informations d’identification qui s’exécutaient lors de l’importation. Un seul fichier de flux de travail malveillant a exposé des secrets sur l’ensemble des pipelines CI/CD.
Pourquoi les environnements de développement d’IA sont particulièrement exposés
La plupart des attaques contre la chaîne d’approvisionnement sont mauvaises. Les attaques contre la chaîne d’approvisionnement ciblant les environnements de développement de l’IA sont encore pires.
Les environnements d’IA et de ML combinent développement, recherche, infrastructure cloud, accès aux données, publication de modèles et automatisation au sein du même espace de travail. Un package Python compromis dans une application Web standard peut voler les informations d’identification d’une base de données. La même attaque dans un environnement de développement d’IA peut exposer simultanément les pondérations des modèles, les données d’entraînement, les jetons cloud de plusieurs fournisseurs, les secrets du pipeline CI/CD et les clés API de production, à partir d’une seule dépendance infectée.
Il existe une deuxième couche dont la plupart des équipes de sécurité ne tiennent pas compte. Lorsque les développeurs utilisent des assistants de codage IA pour écrire du code, ces assistants suggèrent fréquemment des directives d’installation pip et des instructions d’importation faisant référence à des packages spécifiques. Si le développeur fait confiance à la suggestion et installe le package nommé, et qu’un attaquant a déjà enregistré un package malveillant sous ce nom, l’attaque réussit sans que l’attaquant n’interagisse jamais directement avec le développeur. Les chercheurs ont nommé cela slopsquatting – et des recherches récentes ont révélé que sur près de 200 000 invites Python, chaque LLM majeur génère des noms de paquets hallucinés qui n’existent pas sur PyPI, créant une surface d’attaque persistante qu’aucune mise à jour de modèle individuelle ne peut pleinement résoudre.
Vos développeurs ne font rien de mal. Ils utilisent les outils qui les rendent productifs. L’hypothèse de sécurité sous-jacente à ces outils est brisée.
3 contrôles qui comptent en ce moment
1. Épinglez vos dépendances et vérifiez leur intégrité
Les spécificateurs de version flottants (requests>=2.0 plutôt que request==2.31.0) permettent aux gestionnaires de packages d’extraire silencieusement les mises à jour contenant du code malveillant. Épinglez chaque dépendance de vos environnements de développement d’IA à une version exacte et vérifiez les sommes de contrôle par rapport à un hachage reconnu. Cela seul aurait limité le rayon d’action de l’attaque LiteLLM aux environnements explicitement mis à niveau vers les versions compromises plutôt qu’à tout environnement exécutant pip install litellm sans contraintes.
2. Auditez les hooks post-installation dans votre pipeline de développement
L’attaque LiteLLM a intégré sa charge utile à l’aide du mécanisme de fichier .pth de Python, un code qui s’exécute automatiquement lors de l’initialisation de l’interpréteur, avant l’exécution de toute instruction d’importation. Les hooks post-installation et la manipulation de fichiers .pth sont une classe d’attaque documentée, mais leur application dans les environnements de développement est incohérente. Exiger la révision des packages qui incluent des scripts de post-installation avant qu’ils n’atteignent les machines des développeurs. Des outils tels que Socket et Sonatype fournissent une analyse en temps réel des packages PyPI pour détecter tout comportement malveillant avant l’installation. Ce n’est pas agréable à avoir. Compte tenu du rythme d’adoption des outils d’IA, il s’agit d’un contrôle basique.
3. Faites pivoter les informations d’identification cloud immédiatement après toute exposition suspectée
La charge utile LiteLLM ciblait spécifiquement les jetons AWS, GCP et Azure, car ces informations d’identification permettent un mouvement latéral à travers les environnements cloud. Si vos pipelines de développement ont retiré LiteLLM pendant la fenêtre d’exposition du 24 mars, considérez tous les identifiants cloud accessibles à partir de ces environnements comme potentiellement compromis et faites-les alterner. Examinez les journaux d’audit de votre fournisseur de cloud pour détecter les modèles d’activité qui ne correspondent pas aux demandes initiées par le développeur (la signature d’un jeton volé utilisé par un attaquant dans un emplacement différent).
Ce que cela signifie pour les équipes de sécurité
La campagne TeamPCP ne marque pas la fin de cette tendance. C’est une preuve de concept que l’infrastructure d’IA est désormais une classe cible. LiteLLM, PyTorch Lightning et les outils intermédiaires sont des packages dont vos équipes d’IA dépendent quotidiennement. Les attaquants le savent. Ils savent que les développeurs évoluent rapidement, que l’adoption des outils d’IA dépasse les cycles d’examen de la sécurité et qu’un fichier .pth malveillant est invisible pour la plupart des produits de détection des points finaux.
Les contrôles ci-dessus ne sont pas complexes. Ils ne nécessitent pas de nouveaux fournisseurs ou de nouvelles plates-formes. Ils nécessitent de traiter l’installation des packages Python dans les environnements de développement d’IA avec la même rigueur que celle que vous appliquez aux déploiements de production, car en 2026, la distance entre l’environnement local d’un développeur et votre infrastructure de production est plus courte que jamais, et les attaquants l’ont remarqué.
Vos développeurs font confiance à leurs outils. Assurez-vous que la confiance est garantie.
