Cybersécurité

CloudSEK relie une faille de chaîne d’approvisionnement de LiteLLM en mars à 2 500 organisations

mm
Ajouter Unite.AI à vos sources préférées sur Google

L’entreprise de renseignement sur les menaces CloudSEK a indiqué dans un rapport publié le 11 août 2026 qu’elle a identifié plus de 2 500 organisations potentiellement exposées par la faille de chaîne d’approvisionnement de LiteLLM en mars 2026, et a reconstruit environ 434 000 pipelines CI/CD touchés par l’exposition.

Les chiffres proviennent d’un rapport de recherche de CloudSEK basé sur un jeu de données de victimes que l’entreprise affirme avoir obtenu auprès de son équipe de renseignement sur les menaces au cours de la campagne de mars. Le jeu de données de CloudSEK contient des correspondances de haute confiance liées à des domaines d’entreprise, des référentiels, des informations d’identification ou une infrastructure appartenant à des organisations telles que NVIDIA, Samsung Electronics, Cisco Systems, Siemens, S&P Global, ServiceNow, Deloitte, Vodafone, X Corp, Zscaler, FedEx, Volkswagen, Thales et London Stock Exchange Group. L’entreprise est explicite sur ce que signifient les correspondances : une correspondance de haute confiance décrit la force des preuves reliant les informations exposées à une organisation, et non la preuve qu’une organisation a été compromise ou qu’un attaquant a utilisé ce qui a été pris.

L’incident au centre de la recherche a commencé le 24 mars 2026, lorsque le groupe TeamPCP a publié des versions malveillantes de LiteLLM 1.82.7 et 1.82.8 sur l’index de package Python. Les versions compromises ont été supprimées après environ 40 minutes. Cette fenêtre a suffi : les pipelines CI/CD installent les dépendances automatiquement et s’exécutent souvent avec des privilèges étendus, de sorte qu’un package empoisonné se propage à travers les systèmes de construction d’entreprise à la vitesse de la machine sans qu’aucun développeur ne le révise.

Comment un jeton divulgué a atteint 434 000 pipelines

LiteLLM n’a jamais été attaqué directement. La chaîne documentée dans le rapport de CloudSEK commence un cran en amont, avec Trivy, un analyseur de sécurité open source largement utilisé. Un jeton d’automatisation divulgué associé à l’analyseur a été rotatif mais pas entièrement révoqué, laissant une fenêtre d’environ 20 jours pendant laquelle les attaquants ont forcé le code malveillant sur les balises de version publiées de l’analyseur. Puisque le pipeline de construction de LiteLLM a installé Trivy non épinglé du gestionnaire de package du système, l’analyseur compromis a directement afflué dans la construction, et la construction compromise a produit et publié les versions malveillantes 1.82.7 et 1.82.8 sur PyPI. Un jeton non révoqué, trois outils en profondeur.

La conception de la charge utile a rendu compte de la courte fenêtre. La version 1.82.8 a déposé un fichier malveillant .pth dans l’environnement Python, et les fichiers .pth s’exécutent chaque fois que l’interpréteur Python démarre, que LiteLLM soit importé ou non. Cela contourne complètement les protections de script d’installation. Sur les exécuteurs compromis, le voleur de mots de passe que le FBI appelle SANDCLOCK a été élevé à la racine et a balayé les clés SSH, les informations d’identification AWS, Google Cloud et Azure, les jetons de compte de service Kubernetes, les fichiers d’environnement et les secrets CI/CD, en raclant les valeurs de la mémoire du processus que l’outillage essaie normalement de masquer. Les clés cloud provenaient directement du service de métadonnées d’instance, en utilisant l’accès que l’exécuteur avait déjà plutôt que toute faille. Pour les constructions d’IA spécifiquement, la récolte comprenait des clés d’API LLM et une configuration de passerelle : les informations d’identification de l’ensemble de la pile d’IA d’une organisation.

Les données volées ont été chiffrées sous une clé codée en dur et exfiltrées vers un domaine typosquatté. Lorsque l’exfiltration a échoué, le malware a créé un référentiel public à l’intérieur du compte GitHub de la victime et a téléchargé le matériel volé comme un actif de version, ce qui signifie que certaines organisations publiaient leurs propres secrets en plein vue.

Pourquoi le risque a duré plus longtemps que le package

La suppression des versions malveillantes de PyPI n’a pas clos l’incident. Toute copie de mot de passe effectuée pendant que le package empoisonné était actif reste valide jusqu’à ce que le propriétaire le fasse pivoter ou le révoque, et la suppression du package ne fait rien par elle-même. Le FBI a fait le même point dans une avis FLASH du 2 juillet 2026 sur TeamPCP, avertissant que les organisations touchées par la campagne devraient traiter les données et les informations d’identification exfiltrées comme un risque persistant car les acteurs affiliés sont susceptibles de les utiliser longtemps après l’intrusion initiale.

L’avis confirme la portée de la campagne au-delà de LiteLLM : TeamPCP a trojanisé Trivy, l’analyseur de sécurité KICS de Checkmarx, LiteLLM et le SDK Python de Telnyx, des outils intégrés dans les pipelines d’entreprise, l’infrastructure cloud et les flux de travail de sécurité, et a associé les intrusions à l’extorsion, en publiant les noms des victimes sur un site de fuite public et en menaçant de divulguer des données volées.

Les mesures d’atténuation recommandées par le FBI se chevauchent presque exactement avec ce que la chaîne de LiteLLM a exploité : épingler les actions GitHub à des hachages de commit vérifiés plutôt qu’à des balises de version flottantes, faire pivoter chaque secret CI/CD et jeton de publication accessible pendant la fenêtre d’exposition, appliquer une étendue de privilèges minimale aux comptes de service et aux jetons d’enregistrement, et rechercher des référentiels nommés tpcp-docs ou docs-tpcp dans les organisations GitHub, que le malware crée avec des informations d’identification volées.

Ce que signifient les libellés de confiance

CloudSEK trie les organisations dans son jeu de données par force de preuve. Une correspondance de haute confiance repose sur des domaines d’entreprise, des référentiels, des informations d’identification ou une infrastructure identifiables ; une correspondance de confiance moyenne comporte des indicateurs crédibles mais plus faibles. Aucun libellé n’est une preuve d’une attaque réussie, et l’entreprise souligne que le jeu de données est une exposition reconstruite : apparaître dans celui-ci signifie que des informations associées à l’organisation ont été identifiées et doivent être examinées, et non qu’une faille est confirmée.

Une certaine prudence quant à l’échelle est justifiée. Les chiffres de 2 500 organisations et 434 000 pipelines proviennent d’un jeu de données que CloudSEK a obtenu via ses canaux de renseignement et a reconstruit, et l’entreprise vend la plate-forme de surveillance d’exposition AIVigil sur laquelle cette recherche est axée. Rien de tout cela n’entache la campagne sous-jacente : la faille de LiteLLM, sa place dans l’opération TeamPCP plus large, et les classes d’informations d’identification à risque sont corroborées par l’avis du FBI et par l’enregistrement d’incident de mars.

CloudSEK a publié un vérificateur d’exposition gratuit où les organisations peuvent voir si leur infrastructure apparaît dans le jeu de données. Ses conseils pour toute correspondance sont de traiter chaque mot de passe que le processus affecté pouvait lire comme potentiellement exposé jusqu’à validation, d’examiner les journaux d’accès à travers les systèmes cloud, de contrôle de source, d’enregistrement et de cluster, et de faire pivoter largement plutôt que le seul jeton LiteLLM ou la clé du fournisseur de modèle. Pour les organisations qui ont exécuté les versions affectées en mars, la décision de rotation a un compte à rebours de cinq mois qui tourne déjà.

Miles Okada est un analyste généré par IA chez Unite.AI, couvrant l'intelligence artificielle et la cybersécurité avec un accent sur les menaces émergentes, les architectures de défense et la dynamique évolutionnaire entre les attaquants et les systèmes automatisés. Son travail examine comment l'IA réshape les opérations de sécurité, de la détection et de la réponse aux menaces autonomes à l'émergence de techniques d'IA adverses.
Avec une perspective technique et d'investigation, Miles analyse les recherches en matière de sécurité, les divulgations d'incidents et les déploiements dans le monde réel pour comprendre où l'IA renforce les défenses - et où elle introduit de nouvelles vulnérabilités. Il prête une attention particulière à l'exploitation de modèles, à l'empoisonnement de données, à l'automatisation d'attaques et aux réalités opérationnelles de la sécurisation des systèmes alimentés par l'IA à grande échelle.
Les articles rédigés par Miles Okada sont générés par IA et révisés par l'équipe éditoriale d'Unite.AI pour garantir l'exactitude, la rigueur et la couverture responsable du paysage de sécurité de l'IA en évolution rapide.