LiteLLM, le maillon faible qui a exposé des secrets CI/CD

Une compromission de LiteLLM, passerelle open source qui route les requêtes entre modèles d’IA, a exposé des secrets de build chez plus de 2 500 organisations, selon CloudSEK et Hudson Rock. Les versions malveillantes 1.82.7 et 1.82.8 n’ont été en ligne qu’environ 40 minutes en mars 2026, mais elles auraient touché quelque 434 000 pipelines CI/CD. Le sujet compte car il montre comment un simple maillon d’infrastructure peut ouvrir la porte à des clés cloud, des jetons GitHub et des accès à des systèmes d’IA entiers.

Une attaque courte, mais un impact qui dure

Le point de départ remonte au 24 mars 2026, quand le groupe suivi sous le nom de TeamPCP a publié sur PyPI des versions piégées de LiteLLM. Ce court laps de temps a suffi, car les chaînes CI/CD installent souvent leurs dépendances automatiquement, avec des privilèges larges et sans relecture humaine. Résultat : un paquet empoisonné peut se diffuser à la vitesse d’une mise à jour banale, ce qui est rarement banal quand il s’agit de secrets.

CloudSEK explique que son analyse repose sur un jeu de données reconstruit à partir de sa veille de menace, avec des correspondances dites de haute confiance pour des domaines, dépôts, identifiants ou infrastructures liés à des groupes comme NVIDIA, Samsung Electronics, Cisco Systems, Siemens, S&P Global, ServiceNow, Deloitte, Vodafone, X Corp, Zscaler, FedEx, Volkswagen, Thales ou London Stock Exchange Group. Haute confiance ne veut pas dire compromission confirmée : cela indique que les indices lient fortement les données à une organisation, pas qu’un attaquant a forcément exploité le tout.

Le chaînage a commencé plus haut, avec Trivy

LiteLLM n’a pas été ciblé directement. Selon CloudSEK, l’attaque a démarré en amont, via Trivy, un scanner de vulnérabilités très utilisé. Un jeton d’automatisation lié à cet outil a bien été tourné, mais pas entièrement révoqué, laissant une fenêtre d’environ 20 jours pendant laquelle les assaillants ont pu forcer la publication de code malveillant sur des versions balisées. Comme LiteLLM installait Trivy sans verrouillage explicite dans sa chaîne de build, le paquet compromis a été intégré puis redistribué.

Le FBI, dans une alerte FLASH publiée le 2 juillet 2026, a confirmé un périmètre plus large pour TeamPCP, avec des outils aussi touchés que Trivy, KICS de Checkmarx, LiteLLM et le SDK Python de Telnyx. L’agence évoque aussi des extorsions et la publication de noms de victimes sur un site de fuite. Bref, l’attaque ne s’est pas arrêtée au dépôt Python.

Quand les secrets sortent, ils ne rentrent pas tout seuls

La charge utile de LiteLLM 1.82.8 déposait un fichier .pth malveillant dans l’environnement Python. Un fichier .pth s’exécute au démarrage de l’interpréteur, même si le paquet n’est jamais importé, ce qui contourne au passage plusieurs protections habituelles des scripts d’installation. Sur les machines atteintes, le voleur de données appelé SANDCLOCK par le FBI aurait escaladé jusqu’au niveau root, puis récupéré des clés SSH, des identifiants AWS, Google Cloud et Azure, des jetons Kubernetes, des variables d’environnement et des secrets CI/CD.

CloudSEK et Hudson Rock disent aussi avoir observé des clés d’API pour des fournisseurs de modèles, donc des accès à la couche IA elle-même. Les données étaient chiffrées avec une clé codée en dur puis exfiltrées vers un domaine proche d’un nom légitime. Quand l’exfiltration échouait, le malware créait carrément un dépôt public dans le compte GitHub de la victime pour y déposer les fichiers volés. On a déjà vu des fuites de secrets, mais ici certains se sont presque publiés eux-mêmes, ce qui a un petit goût de mauvaise farce informatique.

Pourquoi la fermeture de PyPI ne règle rien

Retirer les versions malveillantes du registre n’efface pas l’incident. Tout secret copié pendant la fenêtre d’exposition reste valable jusqu’à rotation ou révocation. C’est précisément ce qu’insistent à rappeler le FBI, CloudSEK et Hudson Rock : il faut considérer les données récupérées comme exposées de façon persistante, même si le paquet n’est plus disponible.

Hudson Rock parle de 195 téraoctets de fichiers analysés, tandis que CloudSEK dit avoir reconstruit environ 434 000 pipelines touchés. Les chercheurs citent aussi des secrets de Salesforce, Slack et Microsoft Azure dans les dumps observés. La méthode à suivre est assez claire : rotation complète des jetons de publication, des clés cloud, des secrets de cluster, des PAT GitHub ou GitLab, puis audit des journaux et du trafic sortant. En pratique, le mot d’ordre est simple : tout ce que le pipeline pouvait lire doit être considéré comme compromis tant que le contraire n’a pas été démontré.

Les priorités de réponse, sans attendre le prochain paquet piégé

Les recommandations convergent aussi sur la prévention. Le FBI conseille d’épingler les actions GitHub à des commits vérifiés plutôt qu’à des balises flottantes, de limiter les privilèges des comptes de service et de rechercher des dépôts créés par le malware, notamment tpcp-docs ou docs-tpcp. Hudson Rock demande, de son côté, un audit immédiat des versions LiteLLM 1.82.7 et 1.82.8 pour toute organisation utilisant une infrastructure de proxy IA, des scanners CI/CD tiers ou des dépendances de modèles.

CloudSEK propose aussi un vérificateur d’exposition gratuit pour savoir si une infrastructure figure dans son jeu de données. La société précise toutefois que ses scores de confiance ne constituent pas une preuve de piratage, seulement un signal d’exposition à investiguer. Dans ce contexte, la question n’est plus de savoir si la supply chain peut être attaquée. Elle l’est déjà, et un créneau de 40 minutes a suffi pour le rappeler à une échelle plutôt difficile à ignorer.