L’attaque LiteLLM du 24 mars 2026 a commencé par le piratage d’un outil de sécurité. Le groupe TeamPCP a d’abord compromis Trivy, un scanner de vulnérabilités très répandu. Il a ensuite utilisé les identifiants volés pour piéger LiteLLM, une bibliothèque Python qui sert d’interface commune vers les modèles d’intelligence artificielle d’OpenAI, de Google et d’Anthropic. Les versions malveillantes sont restées en ligne une quarantaine de minutes, assez pour exposer un très grand nombre de systèmes.
Trivy, la porte d’entrée de l’attaque LiteLLM
Aqua Security développe Trivy en open source. Des milliers de développeurs s’en servent pour vérifier la sécurité de leur code. Le 19 mars 2026, TeamPCP a utilisé un identifiant compromis pour publier sur le dépôt GitHub de Trivy une fausse version officielle, la v0.69.4. Le groupe a aussi détourné les étiquettes de versions des actions GitHub trivy-action et setup-trivy.
Cette version vérolée volait les identifiants des utilisateurs. Parmi les victimes figurait l’équipe de LiteLLM, qui faisait tourner Trivy pour tester ses propres mises à jour.
Trivy n’a pas été la seule étape. Le 23 mars, selon Wiz, TeamPCP a détourné entre 12h58 et 16h50 UTC les 35 étiquettes de version de l’action GitHub de Checkmarx KICS, un autre outil d’analyse de sécurité. D’après Snyk, la même infrastructure a servi dans les deux opérations. TeamPCP a donc frappé les outils de sécurité avant l’infrastructure d’IA.
Attaque LiteLLM : des versions piégées une quarantaine de minutes
Grâce aux identifiants volés dans la chaîne d’intégration continue de LiteLLM, TeamPCP a pu publier directement sur PyPI, le dépôt officiel des paquets Python, au nom du projet. Le 24 mars 2026, à partir de 10h39 UTC, deux versions malveillantes y sont apparues : 1.82.7 et 1.82.8. Selon 01net, la bibliothèque est téléchargée 3,4 millions de fois par jour.
Le code injecté fouillait les machines infectées. Il aspirait les mots de passe, les clés d’API des clouds AWS, Google Cloud et Azure, les fichiers de configuration Kubernetes, les portefeuilles de cryptomonnaies et les historiques de commandes. Ensuite, il chiffrait et compressait ces données avant de les envoyer vers des serveurs tenus par les attaquants.
Les deux versions ne se déclenchaient pas de la même façon, selon l’analyse de Snyk. Dans la 1.82.7, le code malveillant, encodé en base64, était caché dans le fichier proxy_server.py : il s’exécutait dès qu’un programme importait le module proxy de LiteLLM. La 1.82.8 ajoutait en plus un fichier litellm_init.pth dans le dossier site-packages. Ce type de fichier s’exécute à chaque démarrage de Python, sans aucune importation. Un poste qui avait simplement installé le paquet était donc exposé.
Un développeur de FutureSearch a découvert l’attaque LiteLLM par hasard. Il travaillait avec Cursor, un éditeur de code assisté par l’IA, lorsque sa machine a brutalement ralenti après une installation automatique de LiteLLM. En examinant les processus, il a repéré un élément suspect dans la version 1.82.8.
PyPI a mis les versions piégées en quarantaine après environ 40 minutes, selon l’équipe LiteLLM. Les utilisateurs de l’image Docker officielle du proxy LiteLLM, dont les dépendances sont figées, n’ont pas été touchés. L’équipe demande donc à tous les autres de revenir à la version 1.82.6 et de considérer comme compromis tous les identifiants présents sur les systèmes concernés.
Ce que l’attaque LiteLLM change pour les entreprises
Ben Read, chercheur chez Wiz, rappelle que des outils comme LiteLLM sont présents dans plus d’un tiers des environnements cloud. D’après 01net, Netflix, Stripe ou Google utilisent cette bibliothèque. Un seul maillon compromis contamine ainsi des milliers d’organisations qui n’ont jamais entendu parler de Trivy.
Après l’attaque LiteLLM, vérifiez d’abord vos environnements Python. Cherchez les versions 1.82.7 et 1.82.8 dans vos fichiers de dépendances, vos images et vos postes de développement, y compris ceux qui installent les paquets automatiquement. En cas de doute, renouvelez toutes les clés d’API et tous les mots de passe présents sur la machine.
Par précaution, l’équipe LiteLLM demande de contrôler toute installation ou mise à jour faite le 24 mars entre 10h39 et 16h00 UTC, en particulier sans version figée. Le paquet arrive aussi par dépendance indirecte, par exemple via un framework d’agents ou un serveur MCP. Recherchez ensuite les traces publiées par l’équipe : le fichier litellm_init.pth dans site-packages, et des connexions vers les domaines models.litellm.cloud et checkmarx.zone, étrangers au projet. Une version saine, la 1.83.0, est sortie le 30 mars 2026 d’une nouvelle chaîne de publication, et l’équipe publie les empreintes SHA-256 des versions vérifiées. Figez donc vos dépendances et contrôlez leur empreinte à l’installation.
Secrets volés et données personnelles : les obligations RGPD
Une clé d’API cloud volée ouvre l’accès aux données que ce service traite, et notamment aux données personnelles de vos clients ou de vos salariés. Si cet accès présente un risque pour les personnes, l’article 33 du RGPD impose de notifier la Commission nationale de l’informatique et des libertés (CNIL) dans les 72 heures. Lorsque le risque est élevé, l’article 34 impose en plus d’informer les personnes concernées. Notre tutoriel pour notifier une violation de données personnelles détaille la démarche.
Une bibliothèque open source n’est pas un sous-traitant au sens de l’article 28, car son éditeur ne traite aucune donnée pour votre compte. En revanche, chaque dépendance intégrée à un système qui traite des données relève de votre obligation de sécurité au titre de l’article 32. Inscrivez donc les dépendances critiques dans la cartographie des risques, au même titre que les serveurs. L’épisode de Trivy, analysé dans notre article Trivy empoisonné, montre qu’un outil de sécurité figure lui aussi dans cette liste.
Tracez enfin chaque incident, même sans notification, dans le registre des violations. Un outil comme DPO Suite, l’application de conformité de DPO PARTAGE, tient ce registre et garde la trace de la décision de notifier ou non.
Sources
L’équipe LiteLLM détaille la chronologie, les versions touchées, les indicateurs de compromission et la version saine 1.83.0 dans Security Update: Suspected Supply Chain Incident.
The Hacker News décrit la compromission de Trivy dans Trivy Security Scanner GitHub Actions Breached, 75 Tags Hijacked to Steal CI/CD Secrets.
Snyk détaille les deux modes de déclenchement et la chronologie dans How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM.
Wiz décrit l’attaque contre l’action GitHub de KICS dans KICS GitHub Action Compromised: TeamPCP Strikes Again in Supply Chain Attack.
Le volume de téléchargements et les entreprises utilisatrices sont cités par 01net dans Une cyberattaque au cœur de l’IA sème la panique chez les développeurs.
