Faille LiteLLM : la fuite qui interroge les passerelles API pour LLM

L’incident, révélé au cœur de l’été 2026 par les cabinets CloudSEK puis Hudson Rock, illustre un scénario redouté par les équipes de sécurité : la compromission d’un outil tiers, invisible pour la plupart des utilisateurs finaux, qui se propage jusqu’à une passerelle d’intelligence artificielle largement adoptée. LiteLLM, bibliothèque Python open source et serveur proxy développé par BerriAI, offre une interface unique pour interroger plus d’une centaine de fournisseurs de modèles de langage. C’est précisément cette fonction de point d’entrée unique qui a transformé un incident chez un scanner de sécurité en exposition à l’échelle de tout un écosystème.

Une faille chez Trivy qui se propage jusqu’à LiteLLM

Selon CloudSEK, le groupe TeamPCP, suivi par Google sous le nom UNC6780, n’a jamais visé LiteLLM directement. Le 19 mars 2026, les attaquants ont exploité un jeton d’automatisation révoqué de manière incomplète pour prendre le contrôle de Trivy, le scanner de vulnérabilités open source d’Aqua Security : ils ont forcé la publication de commits malveillants sur 76 des 77 balises de version de trivy-action et sur les sept balises de setup-trivy, tout en publiant une version 0.69.4 de Trivy corrompue.

Le pipeline d’intégration continue de LiteLLM installait Trivy de manière non figée via le gestionnaire de paquets système, ce qui a permis au scanner piégé d’entrer automatiquement dans la chaîne de compilation. Cette compilation empoisonnée a ensuite produit et publié deux versions malveillantes de LiteLLM, 1.82.7 et 1.82.8, sur PyPI. Le projet situe leur mise en ligne le 24 mars à partir de 10h39 UTC, pour une durée d’environ 40 minutes avant leur retrait, tout en recommandant de considérer comme suspecte toute installation réalisée ce jour-là jusqu’à 16h00 UTC.

Le mécanisme technique explique l’ampleur des dégâts : la version 1.82.8 contenait un fichier litellm_init.pth, exécuté automatiquement au démarrage de l’interprèteur Python, sans qu’aucune importation explicite de LiteLLM soit nécessaire. Le code malveillant s’exécutait donc sur tout système ayant simplement installé le paquet, y compris lorsque celui-ci arrivait via une dépendance transitive non maîtrisée, par exemple intégrée par un cadre d’orchestration d’agents. La vulnérabilité est désormais suivie sous la référence CVE-2026-33634, ajoutée au catalogue des vulnérabilités exploitées connues de la CISA le 26 mars 2026, qui liste les versions BerriAI LiteLLM 1.82.7 à 1.82.8 aux côtés des composants Trivy.

Les comptes rendus publiés divergent sur la mécanique exacte de publication : CloudSEK attribue la publication à la compilation empoisonnée elle-même, le rapport d’incident de LiteLLM évoque un téléversement direct sur PyPI qui a contourné le flux officiel d’intégration continue, et l’analyse de Unit 42 décrit des attaquants ayant visé directement les jetons de publication PyPI après la compromission de Trivy. Interrogée sur cet écart, CloudSEK a indiqué qu’il s’agit d’étapes différentes d’une même chaîne d’attaque plutôt que d’explications concurrentes.

Une ampleur difficile à fixer avec certitude

Deux cabinets distincts ont reconstitué l’exposition à partir de jeux de données différents, ce qui donne des chiffres proches mais pas identiques.

CloudSEK insiste sur un point essentiel : ces chiffres décrivent une exposition reconstituée et ne prouvent pas que chaque organisation listée a effectivement été compromise, ni que chaque identifiant a été volé. Chaque cas doit faire l’objet d’une vérification indépendante. Le chercheur en sécurité Kevin Beaumont, cité par Help Net Security, a toutefois indiqué avoir confirmé la légitimité des données auprès de plusieurs organisations victimes, tout en soulignant que la faille résulte d’une sécurité DevOps insuffisante autour de déploiements d’IA menés dans l’urgence, plutôt que d’un défaut intrinsèque de l’IA elle-même. Il rapporte également qu’une entreprise technologique américaine de premier plan lui avait affirmé avoir tout fait tourner, avant qu’un test mené dans le cadre de sa propre politique de divulgation responsable ne montre que la quasi-totalité des identifiants récupérés fonctionnait encore.

Parmi les organisations figurant dans les listes de CloudSEK à haute confiance, on trouve Nvidia, AWS, Samsung, Salesforce, Cisco, ServiceNow, Siemens, Volkswagen, Deutsche Bahn, FedEx, la London Stock Exchange Group, Deloitte, X Corp et, pour la France, Orange. CloudSEK précise que ces correspondances reposent sur des signaux d’identité comme le domaine de l’organisation apparaissant dans les journaux capturés, et qu’une correspondance à haute confiance déclenche une obligation de validation privé, de notification et d’examen des journaux, pas une confirmation publique de compromission.

Ce que les attaquants ont pu récupérer

Les paquets corrompus étaient conçus pour collecter les variables d’environnement, les clés SSH, les identifiants cloud, les jetons Kubernetes et les mots de passe de bases de données avant de chiffrer et d’exfiltrer ces données. L’analyse de Unit 42 relevée par The Hacker News signale que le programme lisait notamment les variables d’environnement contenant des clés d’API de modèles, dont OPENAI_API_KEY et ANTHROPIC_API_KEY. Le tableau ci-dessous reprend les catégories de secrets identifiées par CloudSEK comme potentiellement accessibles sur un système touché.

Un détail aggrave la portée de l’incident : la suppression du paquet malveillant n’a pas mis fin à l’exposition. Les systèmes de compilation automatisés copient rapidement un artefact malveillant, via les tâches planifiées, les résolveurs de dépendances, les exécuteurs éphémères ou les couches mises en cache. La fenêtre de rotation des identifiants s’étend donc bien au-delà des 40 minutes de disponibilité du paquet sur PyPI.

Le risque propre à la centralisation des passerelles LLM

LiteLLM a été adopté massivement précisément pour répondre à la fragmentation des API de modèles de langage : plutôt que de gérer un SDK, un système d’authentification et un format de requête par fournisseur, une organisation route tout son trafic IA par un point unique. Cette même centralisation est ce qui a transformé une fuite d’identifiants isolée chez Trivy en exposition à l’échelle de tout un écosystème. Une passerelle qui interconnecte plusieurs fournisseurs de LLM concentre par construction les clés cloud, les jetons Kubernetes, les identifiants de bases de données et les clés d’API des fournisseurs d’IA qui transitent par elle. Compromettre ce point de jonction expose donc bien davantage que le seul trafic vers les modèles de langage.

CloudSEK formule ce constat sans ambiguïté : la prochaine vague d’attaques majeures visera probablement l’infrastructure d’IA elle-même, car ces systèmes sont devenus des points de jonction à forte valeur ajoutée entre les données, l’identité, la puissance de calcul et l’action autonome. Pour une entreprise française qui interconnecte ses applications à plusieurs fournisseurs de LLM via une passerelle auto-hébergée, l’épisode invite à se poser des questions concrètes : où sont stockés et renouvelés les secrets sous-jacents, la chaîne de dépendances est-elle figée et auditée, et le trafic vers les fournisseurs tiers transite-t-il après un premier filtrage des données à caractère personnel.

Certaines plateformes proposent un modèle différent : donner accès à plusieurs fournisseurs de modèles via un abonnement géré par un éditeur, plutôt que de faire fonctionner soi-même une passerelle et de gérer directement les secrets de chaque vendeur de LLM. Moon AI, plateforme française éditée par Stellarr Studio SAS, fonctionne sur ce principe en donnant accès à plus de 100 modèles, dont GPT, Claude, Gemini, Mistral, DeepSeek, Llama, Grok, Qwen et le modèle maison Moon 6, au sein d’un abonnement unique. L’application et le stockage sont hébergés chez OVHcloud, à Strasbourg et Roubaix, mais les requêtes adressées aux modèles tiers partent bien vers l’infrastructure de leurs fournisseurs respectifs. Moon Blur remplace au préalable les données à caractère personnel par des jetons avant cet envoi, puis les rétablit au retour : le modèle ne reçoit que des repères, et les données personnelles détectées sont ainsi sécurisées.

Réagir sans attendre une preuve de compromission

Le FBI a publié le 2 juillet 2026 un bulletin FLASH (FLASH-20260702-01) avertissant que des acteurs liés à la campagne sont susceptibles d’exploiter les identifiants récupérés bien après l’intrusion initiale. L’agence recommande de renouveler les secrets d’intégration continue, les jetons de publication et les identifiants cloud accessibles pendant la fenêtre d’exposition, et invite les organisations à abandonner les jetons de longue durée pour des identifiants temporaires.

Les recommandations convergentes de CloudSEK, Hudson Rock et du projet LiteLLM tiennent en quelques points :

• Vérifier la présence des versions 1.82.7 ou 1.82.8 de LiteLLM installées pendant la fenêtre du 24 mars 2026, de 10h39 à 16h00 UTC.
• Considérer comme compromis tout secret accessible au processus LiteLLM, qu’il soit présent en mémoire, injecté dans une tâche, stocké sur disque ou récupérable via un service de métadonnées d’instance.
• Renouveler ces secrets ainsi que les comptes de service et les sessions associées, sans attendre une preuve formelle d’utilisation malveillante.
• Examiner les journaux depuis le 24 mars pour détecter des activités anormales, et rechercher d’éventuels dépôts nommés tpcp-docs ou docs-tpcp, indicateurs de la campagne relevés par le FBI.

Questions fréquentes

Mon organisation utilise LiteLLM, comment savoir si elle est concernée ?

Il faut vérifier si les versions 1.82.7 ou 1.82.8 ont été installées, notamment entre le 24 mars 2026 à 10h39 UTC et 16h00 UTC selon la fenêtre d’audit retenue par le projet. CloudSEK a publié un outil de consultation public permettant de rechercher un nom ou un domaine, avec un niveau de confiance associé à chaque correspondance.

Faut-il renoncer aux passerelles LLM auto-hébergées ?

Les sources ne permettent pas d’affirmer que l’auto-hébergement est en soi plus risqué qu’un service géré. L’incident montre en revanche que la chaîne de dépendances d’une passerelle, y compris des outils annexes comme un scanner de vulnérabilités installé automatiquement, doit être figée et auditée, et que les protections classiques comme le blocage des scripts d’installation n’empêchent pas un fichier .pth de s’exécuter au démarrage de l’interprèteur.

Les entreprises françaises citées, comme Orange, sont-elles confirmées compromises ?

Non. CloudSEK précise explicitement que les chiffres de plus de 2500 organisations et 434000 pipelines décrivent une exposition reconstituée à partir de fichiers capturés, et non une preuve que chaque organisation listée a été effectivement compromise ou que chaque identifiant a été volé. Chaque cas nécessite une vérification indépendante.

Que change cet épisode pour les entreprises qui interrogent plusieurs fournisseurs de LLM ?

Il rappelle que router le trafic vers plusieurs fournisseurs de modèles par un point unique concentre aussi, par construction, les identifiants qui transitent par ce point. La question posée n’est pas seulement celle du choix d’un fournisseur de modèle, mais celle de la gestion des secrets, de la chaîne de dépendances et de la localisation de l’hébergement de l’outil qui centralise ces accès.