L'incident, revele au coeur de l'ete 2026 par les cabinets CloudSEK puis Hudson Rock, illustre un scenario redoute par les equipes de securite : la compromission d'un outil tiers, invisible pour la plupart des utilisateurs finaux, qui se propage jusqu'a une passerelle d'intelligence artificielle largement adoptee. LiteLLM, bibliotheque Python open source et serveur proxy developpe par BerriAI, offre une interface unique pour interroger plus d'une centaine de fournisseurs de modeles de langage. C'est precisement cette fonction de point d'entree unique qui a transforme un incident chez un scanner de securite en exposition a l'echelle de tout un ecosysteme.
Une faille chez Trivy qui se propage jusqu'a LiteLLM
Selon CloudSEK, le groupe TeamPCP, suivi par Google sous le nom UNC6780, n'a jamais vise LiteLLM directement. Le 19 mars 2026, les attaquants ont exploite un jeton d'automatisation revoque de maniere incomplete pour prendre le controle de Trivy, le scanner de vulnerabilites open source d'Aqua Security : ils ont force 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'integration continue de LiteLLM installait Trivy de maniere non figee via le gestionnaire de paquets systeme, ce qui a permis au scanner piege d'entrer automatiquement dans la chaine de compilation. Cette compilation empoisonnee a ensuite produit et publie deux versions malveillantes de LiteLLM, 1.82.7 et 1.82.8, sur PyPI. Le projet situe leur mise en ligne le 24 mars a partir de 10h39 UTC, pour une duree d'environ 40 minutes avant leur retrait, tout en recommandant de considerer comme suspecte toute installation realisee ce jour-la jusqu'a 16h00 UTC.
Le mecanisme technique explique l'ampleur des degats : la version 1.82.8 contenait un fichier litellm_init.pth, execute automatiquement au demarrage de l'interpreteur Python, sans qu'aucune importation explicite de LiteLLM soit necessaire. Le code malveillant s'executait donc sur tout systeme ayant simplement installe le paquet, y compris lorsque celui-ci arrivait via une dependance transitive non maitrisee, par exemple integree par un cadre d'orchestration d'agents. La vulnerabilite est desormais suivie sous la reference CVE-2026-33634, ajoutee au catalogue des vulnerabilites exploitees connues de la CISA le 26 mars 2026, qui liste les versions BerriAI LiteLLM 1.82.7 a 1.82.8 aux cotes des composants Trivy.
Les comptes rendus publies divergent sur la mecanique exacte de publication : CloudSEK attribue la publication a la compilation empoisonnee elle-meme, le rapport d'incident de LiteLLM evoque un televersement direct sur PyPI qui a contourne le flux officiel d'integration continue, et l'analyse de Unit 42 decrit des attaquants ayant vise directement les jetons de publication PyPI apres la compromission de Trivy. Interrogee sur cet ecart, CloudSEK a indique qu'il s'agit d'etapes differentes d'une meme chaine d'attaque plutot que d'explications concurrentes.
Une ampleur difficile a fixer avec certitude
Deux cabinets distincts ont reconstitue l'exposition a partir de jeux de donnees differents, ce qui donne des chiffres proches mais pas identiques.
| Source | Base de l'estimation | Chiffres avances |
|---|---|---|
| CloudSEK | Dataset reconstitue a partir de fichiers captures par les attaquants | Plus de 2500 organisations, 434000 pipelines CI/CD potentiellement exposes |
| Hudson Rock | Archive de 153 Go analysee, 433909 fichiers | 118829 dumps d'executeurs CI attribues a 2488 domaines d'entreprise |
CloudSEK insiste sur un point essentiel : ces chiffres decrivent une exposition reconstituee et ne prouvent pas que chaque organisation listee a effectivement ete compromise, ni que chaque identifiant a ete vole. Chaque cas doit faire l'objet d'une verification independante. Le chercheur en securite Kevin Beaumont, cite par Help Net Security, a toutefois indique avoir confirme la legitimite des donnees auprès de plusieurs organisations victimes, tout en soulignant que la faille resulte d'une securite DevOps insuffisante autour de deploiements d'IA menes dans l'urgence, plutot que d'un defaut intrinseque de l'IA elle-meme. Il rapporte egalement qu'une entreprise technologique americaine de premier plan lui avait affirme avoir tout fait tourner, avant qu'un test mene dans le cadre de sa propre politique de divulgation responsable ne montre que la quasi-totalite des identifiants recuperes fonctionnait encore.
Parmi les organisations figurant dans les listes de CloudSEK a 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 precise que ces correspondances reposent sur des signaux d'identite comme le domaine de l'organisation apparaissant dans les journaux captures, et qu'une correspondance a haute confiance declenche une obligation de validation prive, de notification et d'examen des journaux, pas une confirmation publique de compromission.
Ce que les attaquants ont pu recuperer
Les paquets corrompus etaient concus pour collecter les variables d'environnement, les cles SSH, les identifiants cloud, les jetons Kubernetes et les mots de passe de bases de donnees avant de chiffrer et d'exfiltrer ces donnees. L'analyse de Unit 42 relevee par The Hacker News signale que le programme lisait notamment les variables d'environnement contenant des cles d'API de modeles, dont OPENAI_API_KEY et ANTHROPIC_API_KEY. Le tableau ci-dessous reprend les categories de secrets identifiees par CloudSEK comme potentiellement accessibles sur un systeme touche.
| Categorie de secret | Exemples | Consequence potentielle |
|---|---|---|
| Identifiants cloud | Cles AWS, GCP, Azure, jetons du service de metadonnees | Prise de controle de comptes, acces aux donnees, abus de calcul |
| Acces au controle de code source | Jetons GitHub/GitLab, cles SSH, cles de deploiement | Vol de code, commits malveillants, decouverte d'autres secrets |
| Publication de paquets | Jetons npm, PyPI, registres de conteneurs | Compromission en cascade de la chaine d'approvisionnement |
| Kubernetes et CI/CD | Jetons de cluster, secrets d'executeurs, comptes de service | Prise de controle de charges de travail, mouvement lateral |
| Acces aux fournisseurs d'IA | Cles d'API de modeles, identifiants de passerelle | Exposition de requetes et de donnees, abus de modele, fraude sur les couts |
| Secrets applicatifs | Fichiers .env, URL de bases de donnees, cles SaaS | Vol de donnees, usurpation, compromission operationnelle |
Un detail aggrave la portee de l'incident : la suppression du paquet malveillant n'a pas mis fin a l'exposition. Les systemes de compilation automatises copient rapidement un artefact malveillant, via les taches planifiees, les resolveurs de dependances, les executeurs ephemeres ou les couches mises en cache. La fenetre de rotation des identifiants s'etend donc bien au-dela des 40 minutes de disponibilite du paquet sur PyPI.
Le risque propre a la centralisation des passerelles LLM
LiteLLM a ete adopte massivement precisement pour repondre a la fragmentation des API de modeles de langage : plutot que de gerer un SDK, un systeme d'authentification et un format de requete par fournisseur, une organisation route tout son trafic IA par un point unique. Cette meme centralisation est ce qui a transforme une fuite d'identifiants isolee chez Trivy en exposition a l'echelle de tout un ecosysteme. Une passerelle qui interconnecte plusieurs fournisseurs de LLM concentre par construction les cles cloud, les jetons Kubernetes, les identifiants de bases de donnees et les cles 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 modeles de langage.
CloudSEK formule ce constat sans ambiguite : la prochaine vague d'attaques majeures visera probablement l'infrastructure d'IA elle-meme, car ces systemes sont devenus des points de jonction a forte valeur ajoutee entre les donnees, l'identite, la puissance de calcul et l'action autonome. Pour une entreprise francaise qui interconnecte ses applications a plusieurs fournisseurs de LLM via une passerelle auto-hebergee, l'episode invite a se poser des questions concretes : ou sont stockes et renouveles les secrets sous-jacents, la chaine de dependances est-elle figee et auditee, et le trafic vers les fournisseurs tiers transite-t-il apres un premier filtrage des donnees a caractere personnel.
Certaines plateformes proposent un modele different : donner acces a plusieurs fournisseurs de modeles via un abonnement geré par un editeur, plutot que de faire fonctionner soi-meme une passerelle et de gerer directement les secrets de chaque vendeur de LLM. Moon AI, plateforme francaise editee par Stellarr Studio SAS, fonctionne sur ce principe en donnant acces a plus de 70 modeles, dont GPT, Claude, Gemini, Mistral, DeepSeek, Llama, Grok, Qwen et le modele maison Moon 6, au sein d'un abonnement unique. L'application et le stockage sont heberges chez OVHcloud, a Strasbourg et Roubaix, mais les requetes adressees aux modeles tiers partent bien vers l'infrastructure de leurs fournisseurs respectifs. Moon Blur remplace au prealable les donnees a caractere personnel par des jetons avant cet envoi, puis les retablit au retour : ce procede etant reversible, il s'agit d'une pseudonymisation au sens de l'article 4-5 du RGPD, pas d'une anonymisation, et il ne supprime pas le risque qu'une cle d'API soit un jour exposee en cas d'incident chez un fournisseur.
Reagir sans attendre une preuve de compromission
Le FBI a publie le 2 juillet 2026 un bulletin FLASH (FLASH-20260702-01) avertissant que des acteurs lies a la campagne sont susceptibles d'exploiter les identifiants recuperes bien apres l'intrusion initiale. L'agence recommande de renouveler les secrets d'integration continue, les jetons de publication et les identifiants cloud accessibles pendant la fenetre d'exposition, et invite les organisations a abandonner les jetons de longue duree pour des identifiants temporaires.
Les recommandations convergentes de CloudSEK, Hudson Rock et du projet LiteLLM tiennent en quelques points :
- Verifier la presence des versions 1.82.7 ou 1.82.8 de LiteLLM installees pendant la fenetre du 24 mars 2026, de 10h39 a 16h00 UTC.
- Considerer comme compromis tout secret accessible au processus LiteLLM, qu'il soit present en memoire, injecte dans une tache, stocke sur disque ou recuperable via un service de metadonnees d'instance.
- Renouveler ces secrets ainsi que les comptes de service et les sessions associees, sans attendre une preuve formelle d'utilisation malveillante.
- Examiner les journaux depuis le 24 mars pour detecter des activites anormales, et rechercher d'eventuels depots nommes tpcp-docs ou docs-tpcp, indicateurs de la campagne releves par le FBI.
Questions frequentes
Mon organisation utilise LiteLLM, comment savoir si elle est concernee ?
Il faut verifier si les versions 1.82.7 ou 1.82.8 ont ete installees, notamment entre le 24 mars 2026 a 10h39 UTC et 16h00 UTC selon la fenetre d'audit retenue par le projet. CloudSEK a publie un outil de consultation public permettant de rechercher un nom ou un domaine, avec un niveau de confiance associe a chaque correspondance.
Faut-il renoncer aux passerelles LLM auto-hebergees ?
Les sources ne permettent pas d'affirmer que l'auto-hebergement est en soi plus risque qu'un service gere. L'incident montre en revanche que la chaine de dependances d'une passerelle, y compris des outils annexes comme un scanner de vulnerabilites installe automatiquement, doit etre figee et auditee, et que les protections classiques comme le blocage des scripts d'installation n'empechent pas un fichier .pth de s'executer au demarrage de l'interpreteur.
Les entreprises francaises citees, comme Orange, sont-elles confirmees compromises ?
Non. CloudSEK precise explicitement que les chiffres de plus de 2500 organisations et 434000 pipelines decrivent une exposition reconstituee a partir de fichiers captures, et non une preuve que chaque organisation listee a ete effectivement compromise ou que chaque identifiant a ete vole. Chaque cas necessite une verification independante.
Que change cet episode pour les entreprises qui interrogent plusieurs fournisseurs de LLM ?
Il rappelle que router le trafic vers plusieurs fournisseurs de modeles par un point unique concentre aussi, par construction, les identifiants qui transitent par ce point. La question posee n'est pas seulement celle du choix d'un fournisseur de modele, mais celle de la gestion des secrets, de la chaine de dependances et de la localisation de l'hebergement de l'outil qui centralise ces acces.