La faille LiteLLM est restée cachée cinq mois

Ce qui s'est passé dans le pipeline de compilation de LiteLLM en mars

L'intrusion n'a pas commencé chez LiteLLM. TeamPCP a d'abord compromis le scanner de sécurité open source Trivy en exploitant un jeton d'automatisation divulgué, obtenant une fenêtre d'environ 20 jours à l'intérieur même du dépôt de Trivy avant que quiconque ne le remarque. Pendant cette fenêtre, le groupe a forcé l'insertion de code malveillant dans les tags de version de Trivy - les marqueurs de version précis vers lesquels pointent les projets en aval lorsqu'ils récupèrent une dépendance.

Le pipeline d'intégration continue de LiteLLM installait Trivy sans le figer à une version vérifiée, si bien qu'il a automatiquement récupéré la version empoisonnée lors de l'exécution suivante du pipeline. Cette seule dépendance non figée a suffi à TeamPCP: le code malveillant s'est infiltré dans le processus de compilation de LiteLLM lui-même, puis dans deux paquets publiés, les versions 1.82.7 et 1.82.8 de LiteLLM, mises en ligne sur le Python Package Index.

La défense à laquelle tout le monde fait confiance, et comment elle a été contournée

La plupart des développeurs qui craignent les paquets PyPI malveillants comptent sur le drapeau --ignore-scripts, qui empêche les scripts d'installation d'un paquet d'exécuter du code arbitraire. La charge utile de TeamPCP n'avait pas besoin de script d'installation. Elle était logée dans un fichier .pth, un fichier de configuration de chemins Python que l'interpréteur exécute lui-même automatiquement au démarrage, à chaque exécution, quelle que soit la manière dont le paquet a été installé. Ce choix de conception est le détail que tous les titres consacrés à cette faille ont omis, et c'est celui qui compte le plus pour toute équipe d'ingénierie qui pensait que --ignore-scripts la protégeait précisément de cette classe d'attaque.

Une fois en cours d'exécution, la charge utile collectait des clés SSH, des identifiants cloud pour AWS, Google Cloud et Azure, des jetons Kubernetes, le contenu des fichiers .env et des clés API de fournisseurs d'IA sur toute machine ayant installé le paquet empoisonné. Les données volées étaient chiffrées en AES-256 et envoyées soit vers un domaine de typosquatting conçu pour ressembler à une ressource légitime de LiteLLM ou de Trivy, soit téléversées directement dans des dépôts sur le propre compte GitHub de la victime - un détail qui permettait à l'opération de se fondre dans une activité de développeur d'apparence normale plutôt que de déclencher une alerte évidente de trafic sortant.

2 500 entreprises, huit nommées en Europe, et un écart de cinq mois

CloudSEK a publié ses recherches le 11 août 2026, cinq mois après la compromission de mars, identifiant plus de 2 500 organisations et environ 434 000 pipelines CI/CD comme potentiellement exposés - ce que la société qualifie de plus grande faille de la chaîne d'approvisionnement en IA découverte à ce jour en 2026. Parmi les correspondances à haute confiance nommées par CloudSEK figurent Siemens AG, Siemens Energy, Deutsche Bahn AG, Orange S.A., Vodafone Group Plc, London Stock Exchange Group, l'énergéticien finlandais Fortum Oyj et le réassureur Munich Re, couvrant l'industrie, les télécommunications, le ferroviaire, la finance et l'assurance dans plusieurs juridictions européennes.

CloudSEK précise explicitement que l'apparition d'une entreprise dans son jeu de données ne prouve pas automatiquement une faille réussie - la conclusion signifie que des identifiants, domaines, dépôts ou infrastructures liés à cette organisation sont apparus dans les données collectées, et chaque organisation doit mener sa propre enquête pour confirmer ce qui, le cas échéant, a effectivement été pris ou détourné. Ce qui ne fait aucun doute, c'est l'écart de cinq mois entre l'intrusion de mars et la divulgation d'août, une fenêtre pendant laquelle chacune des organisations nommées a pu fonctionner sur une infrastructure avec des identifiants compromis, sans avertissement public que la compromission avait eu lieu.

Ce que cela signifie pour quiconque exploite des outils d'infrastructure IA

L'alerte FLASH du FBI de juillet 2026 ajoute un détail gênant à la chronologie: les identifiants collectés en mars sont toujours considérés comme actifs et utilisables des mois plus tard, et le bureau s'attend à ce que TeamPCP ou des acteurs affiliés les exploitent dans de futures intrusions sans rapport plutôt que de les laisser expirer. Pour toute organisation ayant fait tourner les versions 1.82.7 ou 1.82.8 de LiteLLM en production ou en CI durant mars 2026, la bonne réponse n'est pas d'attendre une confirmation individuelle de CloudSEK ou de LiteLLM - c'est de traiter chaque identifiant ayant touché ce pipeline de compilation comme compromis et de le faire tourner dès maintenant, cinq mois de retard ou non.

La leçon structurelle dépasse LiteLLM. Toute organisation qui laisse son pipeline CI récupérer une dépendance d'outillage de sécurité, comme un scanner, sans la figer à une version vérifiée, présente la même ouverture que TeamPCP a exploitée ici, et --ignore-scripts n'est pas la protection que la plupart des équipes croient avoir contre une charge utile livrée via un fichier .pth. Les responsables de la sécurité européens qui exploitent des outils d'infrastructure IA construits sur la même chaîne d'approvisionnement open source devraient voir ceci moins comme une histoire propre à LiteLLM que comme un aperçu de la manière dont la prochaine compromission d'outils IA sera vraisemblablement livrée.

À lire ensuite: 141 006 tests, trois intrusions réelles  |  Micron: 2027 sera plus tendu que 2026