Cyberattaque LiteLLM : deux versions piégées ont volé les secrets de milliers de développeurs IA
récit, ampleur réelle et suites judiciaires.

LiteLLM sert de passerelle unifiée vers les grands modèles de langage. Une seule interface, et derrière elle les API d’OpenAI, d’Anthropic, de Google et de dizaines d’autres fournisseurs. C’est une brique d’infrastructure discrète, installée par réflexe dans les projets d’intelligence artificielle, et sa position d’intermédiaire explique exactement pourquoi elle a été visée.

Le 24 mars 2026 à 10 h 39 UTC, la version 1.82.7 est publiée sur PyPI. Le code malveillant y est glissé dans le fichier proxy_server.py : il s’exécute au démarrage du proxy LiteLLM. Efficace, mais visible à la relecture. Treize minutes plus tard, à 10 h 52, la version 1.82.8 arrive avec une méthode nettement plus agressive : un fichier nommé litellm_init.pth, déclenché à chaque démarrage de l’interpréteur Python dès lors que le paquet est présent dans l’environnement. Plus besoin d’importer quoi que ce soit.

Cette itération en temps quasi réel en dit long. Des analystes ont relevé plusieurs variantes successives du code dans proxy_server.py, signe que l’attaquant testait et affinait pendant la fenêtre d’exposition. Selon l’éditeur, les paquets sont restés en ligne une quarantaine de minutes avant la mise en quarantaine par PyPI ; d’autres analyses évoquent une fenêtre plus large jusqu’au retrait définitif et à la levée de la quarantaine dans la soirée.

La découverte doit beaucoup à un défaut du code lui-même. Le malware provoquait des plantages, ce qui a attiré l’attention plus vite qu’une intrusion silencieuse ne l’aurait permis. Le signalement initial vient de l’équipe FutureSearch, relayé par un ticket public sur le dépôt GitHub du projet. Ce ticket a été fermé, puis noyé sous des centaines de messages automatisés : les comptes des mainteneurs étaient eux-mêmes compromis, au point qu’ils ont dû communiquer depuis des plateformes tierces.

La version initiale du récit parlait d’un maillon de confiance compromis, sans le nommer. Il est désormais identifié, et le détail est plus inconfortable que l’hypothèse d’un mot de passe volé.

Le point de départ se situe le 28 février 2026, avec une première compromission du projet Trivy, le scanner de vulnérabilités d’Aqua Security. Un jeton de compte de service est exfiltré. L’éditeur lance une rotation d’identifiants, mais celle-ci reste incomplète. Le 19 mars, l’attaquant réutilise l’accès conservé pour réécrire de force les étiquettes de version de l’action GitHub aquasecurity/trivy-action, soixante-quinze sur soixante-seize, ainsi que les sept étiquettes de setup-trivy. Chaque commit forgé reprend les métadonnées d’origine, auteur, horodatage et message, en remplaçant le script d’entrée par un voleur d’identifiants. La page de publication ne montrait aucun changement visible.

Le pipeline d’intégration continue de LiteLLM utilisait Trivy. Il a donc exécuté l’action piégée, qui a exfiltré les jetons de publication du projet vers PyPI. Cinq jours plus tard, ces jetons servent à publier directement les deux versions malveillantes, en contournant entièrement le processus habituel passant par GitHub.

La leçon tient en une phrase, et elle est désagréable pour beaucoup d’équipes : l’outil de sécurité qui inspecte le pipeline dispose des mêmes accès que l’outil qui déploie. Quand il tombe, tout ce qui se trouve en aval tombe avec lui. Ce type d’enchaînement rejoint les fragilités déjà observées sur des briques d’intelligence artificielle attaquées dès leur mise en service.

Les chiffres qui circulent méritent d’être distingués selon leur nature. Certains mesurent la popularité du paquet, d’autres estiment le nombre de victimes, et les deux ne se confondent pas.

Côté popularité, LiteLLM se situe autour de plusieurs millions de téléchargements quotidiens, ordre de grandeur cohérent avec les statistiques publiques de PyPI et les estimations relayées par les éditeurs de sécurité. Cela ne signifie pas que tous ces téléchargements sont tombés sur une version piégée : la fenêtre d’exposition se compte en dizaines de minutes, et le nombre réel d’environnements ayant récupéré 1.82.7 ou 1.82.8 n’a pas été publié de façon consolidée.

Côté victimes, l’estimation la plus solide vient des autorités. Dans le cadre de l’enquête sur l’ensemble de la campagne, la police fédérale australienne et le FBI évoquent plus de mille organisations potentiellement compromises, plus de cinq cent mille identifiants et éléments d’authentification exposés, et au moins trois cents gigaoctets de données dérobées. Ces chiffres couvrent toute la campagne, pas le seul épisode LiteLLM.

Un point mérite d’être posé sans dramatiser. Les organisations les plus exposées ne sont pas celles qui ont installé le paquet sur un poste isolé, mais celles dont les serveurs d’intégration continue disposaient de droits étendus. C’est là que se trouvent les clés qui ouvrent le reste, comme l’ont montré les expositions massives provoquées par des outils IA très utilisés et la mise à nu de millions de conversations privées sur DeepSeek.

Traiter LiteLLM comme un accident isolé serait passer à côté de l’essentiel. L’épisode s’inscrit dans une opération continue, attribuée à un groupe se présentant sous le nom de TeamPCP, également suivi sous plusieurs autres pseudonymes.

Entre le 19 et le 25 mars 2026, cinq écosystèmes de distribution logicielle ont été touchés : GitHub Actions, Docker Hub, npm, PyPI et OpenVSX. Au-delà de Trivy et de LiteLLM, la campagne a atteint les actions GitHub de Checkmarx, dont les trente-cinq étiquettes de kics-github-action, deux extensions publiées sur OpenVSX, des images de conteneurs distribuées sur plusieurs registres, et plus de soixante paquets npm contaminés par un composant auto-propagateur. Le 22 mars, quarante-quatre dépôts internes de l’éditeur de Trivy ont été dégradés en quelques minutes. La compromission de Trivy a reçu un identifiant de vulnérabilité et une notation de sévérité critique.

La campagne ne s’est pas arrêtée là. En mai 2026, une seconde vague a frappé plus de cent soixante-dix paquets npm et PyPI, touchant notamment l’écosystème TanStack, très utilisé dans les applications JavaScript modernes, ainsi que des paquets liés à Mistral AI, UiPath et OpenSearch. Mistral AI a confirmé la compromission temporaire d’un de ses systèmes de gestion de code le 12 mai 2026, en précisant que seuls des dépôts non essentiels avaient été atteints et que les services hébergés et les données clients n’étaient pas concernés. Le groupe a ensuite revendiqué la mise en vente de dépôts internes, revendication qui n’a pas été confirmée publiquement.

Cette accumulation raconte une évolution de fond. L’écosystème logiciel qui porte l’intelligence artificielle grossit à une vitesse que ses propres garde-fous ne suivent pas, phénomène visible partout, jusque dans la part désormais considérable du web produite par des modèles génératifs. Le même mécanisme d’effet domino avait déjà été observé sur le vol massif de données clients transitant par Salesforce.

Le 26 août 2026, la police fédérale australienne a annoncé l’interpellation de deux hommes de vingt et un et vingt-trois ans en Australie-Occidentale, à l’issue de perquisitions menées dans la région de Perth. Les deux hommes ont comparu le lendemain devant le tribunal de première instance de Perth. Quatorze chefs d’accusation ont été retenus au total.

L’enquête a été conduite conjointement par la police fédérale australienne, la police d’Australie-Occidentale et le FBI. Elle a démarré en avril 2026, soit le mois suivant les compromissions de Trivy et de LiteLLM, après transmission d’informations par plusieurs sociétés spécialisées en renseignement sur les menaces. Les autorités soutiennent que les deux hommes étaient des participants principaux du groupe et qu’ils ont reçu des paiements en cryptomonnaies dont la valeur reste en cours d’évaluation.

Deux précautions s’imposent. La première tient au droit : il s’agit d’inculpations, pas de condamnations, et la présomption d’innocence s’applique intégralement. La seconde tient à la sécurité opérationnelle : des arrestations ne referment pas une brèche. Les identifiants exfiltrés en mars restent utilisables tant qu’ils n’ont pas été révoqués, quelles que soient les suites judiciaires, et les autorités n’ont pas exclu d’autres interpellations.

Sur le plan institutionnel, l’affaire alimente un mouvement plus large de durcissement réglementaire autour des incidents de sécurité, dans la ligne des alertes de la CNIL sur la montée des cyberattaques systémiques.

L’affaire ne concerne pas seulement les entreprises qui construisent des produits d’intelligence artificielle. Toute organisation dont le site, l’application ou l’outillage interne repose sur des dépendances installées automatiquement est exposée au même mécanisme.

Quatre pratiques changent réellement la donne, et aucune n’exige un budget de grand groupe. Épingler les versions par empreinte cryptographique plutôt que par numéro, de sorte qu’une archive republiée sous le même nom soit rejetée. Interdire ou encadrer strictement l’exécution de code au moment de l’installation, mécanisme précisément exploité par le fichier .pth. Filtrer les flux sortants des serveurs d’intégration continue, qui n’ont aucune raison de contacter un domaine inconnu. Et réduire les droits accordés aux outils du pipeline, y compris aux outils de sécurité, qui héritent souvent de permissions bien plus larges que nécessaire.

S’y ajoute une discipline moins technique mais tout aussi décisive : tenir un inventaire des secrets. Savoir quels jetons existent, où ils vivent, qui les utilise et depuis quand est la condition d’une révocation propre. Sans cet inventaire, une rotation reste un exercice d’approximation, et l’exemple de mars montre où mène l’approximation.

Enfin, la dimension juridique ne peut plus être traitée après coup. Des clés d’API et des accès clients exfiltrés déclenchent des obligations concrètes de notification et de documentation, sujet qui rejoint directement le choc de conformité provoqué par l’intelligence artificielle et les exigences de mise en conformité autour des outils IA. Une équipe qui sait déjà quoi déclarer, à qui et sous quel délai perd beaucoup moins de temps le jour où l’alerte tombe.