La compromission de Trivy serait à l’origine de l’attaque ayant exposé plus de 2 500 organisations

LiteLLM n’aurait été que la phase la plus visible

La compromission de la supply chain de LiteLLM n’aurait pas commencé au sein du projet lui-même. Selon une analyse de SOCRadar, la plupart des plus de 2 500 organisations associées à l’incident avaient auparavant été exposées par l’intermédiaire de Trivy, l’outil d’Aqua Security.

LiteLLM ne serait donc que la dernière étape d’une campagne plus vaste, attribuée au groupe TeamPCP. Cet acteur a déjà été associé à des attaques visant des projets open source ainsi qu’au ver Shai-Hulud.

L’incident a été détecté le 14 août 2026. L’estimation initiale de plus de 2 500 organisations, également relayée par CloudSEK et HudsonRock, ne constitue toutefois pas un recensement des compromissions confirmées. SOCRadar a pu reconstituer, à l’aide d’identifiants attribuables, les données concernant 2 188 entités.

Cette différence s’explique par la disponibilité de données permettant de relier chaque enregistrement à une organisation précise. Dans l’échantillon analysé, 56 % des enregistrements sont classés avec un niveau de confiance élevé, 39 % avec un niveau moyen et 6 % avec un niveau faible.

Les correspondances les plus solides reposent sur l’identité des hôtes CI et les domaines légitimes des contributeurs. Même dans ces cas, l’exposition d’un identifiant ne prouve toutefois pas automatiquement qu’il a été utilisé par l’attaquant.

Le passage de Trivy aux registres logiciels

La campagne a suivi un schéma présentant des caractéristiques de ver informatique. Le code malveillant était exécuté lorsque le paquet compromis était téléchargé et utilisé, puis recherchait les identifiants, tokens, clés API et autres secrets présents dans l’environnement.

Les données collectées pouvaient permettre à l’acteur d’accéder à d’autres dépôts ou registres. Les identifiants des développeurs étaient ensuite réutilisés pour modifier des paquets accessibles à l’attaquant et publier des versions altérées.

Le premier maillon observé dans la chaîne est une build malveillante de Trivy. La première collecte de données a été enregistrée le 19 mars à 18 h 05 UTC, seulement 18 minutes après la publication de la build compromise.

L’activité s’est intensifiée les 22 et 23 mars, lorsque des images Trivy malveillantes étaient disponibles sur Docker Hub. À ce stade, le malware aurait atteint de nombreux environnements de développement et d’intégration continue, en collectant des informations sur les systèmes utilisés pour construire et distribuer des logiciels.

Le 24 mars, deux versions malveillantes de LiteLLM ont été publiées. Les numéros de version exacts n’ont pas été communiqués. Les paquets sont restés disponibles sur PyPI pendant environ 40 minutes avant d’être mis en quarantaine.

Cette période ne correspond pas à la durée totale de l’exposition. Pour SOCRadar, elle constitue uniquement la dernière phase d’une campagne ayant commencé par la compromission de Trivy. La dernière activité détectée remonte au 24 mars à 20 h 09 UTC.

Pour 2 085 organisations, soit 95 % des entités analysées, la collecte des données était déjà terminée avant la publication des paquets LiteLLM. Cet élément renforce l’hypothèse selon laquelle LiteLLM aurait servi d’étape finale ou de vecteur le plus visible, et non de point de départ de l’opération.

Pourquoi le payload .pth a contourné certaines protections

Les paquets LiteLLM altérés contenaient un fichier portant l’extension .pth. Python peut charger et exécuter automatiquement ce type de fichier au démarrage de l’interpréteur, même lorsque l’application n’importe pas directement LiteLLM.

Ce comportement élargit considérablement la surface d’attaque. Une organisation pouvait installer ou démarrer l’environnement compromis sans appeler explicitement le composant malveillant dans son code.

Ce mécanisme permettait également de contourner les protections reposant sur l’option ignore-scripts. Ce paramètre peut empêcher l’exécution de scripts lors de l’installation des paquets, mais ne bloque pas nécessairement le chargement automatique d’un fichier .pth par l’interpréteur Python.

La persistance sur les systèmes déjà infectés constitue un risque supplémentaire. Même après la suppression du paquet d’origine, le payload pouvait continuer à fonctionner dans l’environnement compromis.

La mise en quarantaine des paquets sur PyPI a donc interrompu l’activité observée, mais ne suffit pas à exclure la présence de composants déjà exécutés ou d’identifiants déjà dérobés.

CI/CD, cloud et identités des développeurs dans le viseur

La campagne a concerné six plateformes d’intégration et de déploiement continus :

• GitHub Actions ;
• GitLab CI ;
• Jenkins ;
• Bitbucket ;
• CircleCI ;
• Buildkite.

L’implication de ces environnements est particulièrement sensible. Les pipelines CI/CD disposent souvent d’autorisations permettant de lire le code, de créer des artefacts, de publier des paquets et d’accéder à des infrastructures cloud.

Les organisations touchées étaient réparties dans le monde entier. L’Allemagne, le Brésil et la France sont les pays les plus représentés dans cette reconstitution.

Plus de 1 000 organisations auraient exposé des tokens JWT et des tokens d’authentification. Parmi les autres données identifiées figurent des clés privées, des clés AWS, des tokens GitLab, des clés API OpenAI, des webhooks Slack, des tokens GitHub Actions et des clés API Google.

Les adresses e-mail des contributeurs auraient également été collectées dans plus de 1 100 organisations. L’association entre l’identité des développeurs et des tokens utilisables par des processus automatisés peut faciliter les attaques ciblées, l’usurpation d’identité et l’accès ultérieur aux systèmes de développement.

Certains enregistrements contiennent un nombre exceptionnel de secrets : le plus important en comporterait environ 3 477, tandis qu’un autre en contiendrait environ 3 459 répartis dans seulement six fichiers. Les organisations associées à ces cas n’ont pas été identifiées.

Les données seraient déjà disponibles sur le marché criminel

Les secrets dérobés ne seraient pas restés uniquement dans les systèmes de l’attaquant. Un acteur fait la promotion sur Telegram d’une collection qui inclurait des données attribuées à LiteLLM, Trivy et CanisterWorm.

On ignore si l’ensemble du matériel provient de la même phase de la campagne. La collection pourrait avoir été constituée à différents moments, mais sa disponibilité accroît néanmoins le risque opérationnel pour les organisations exposées.

Les tokens CI/CD, les clés cloud et les identifiants des développeurs peuvent être utilisés pour accéder à des dépôts, modifier des pipelines, publier de nouveaux paquets malveillants ou atteindre des services externes. Les clés API peuvent également engendrer des coûts, permettre l’accès à des données ou être exploitées dans le cadre d’activités automatisées.

La combinaison de la propagation automatique et de la réutilisation des identifiants explique pourquoi l’incident ne doit pas être considéré comme limité à LiteLLM. Un seul paquet compromis peut devenir un point d’entrée vers un réseau de projets, de pipelines et de registres logiciels.

Ce que doivent vérifier les organisations exposées

La seule mesure de confinement documentée est la mise en quarantaine des paquets LiteLLM malveillants par PyPI. Aucun correctif spécifique, aucune version sûre, aucune procédure officielle d’assainissement ni liste complète d’indicateurs techniques n’ont été communiqués.

Les organisations ayant utilisé Trivy ou LiteLLM dans les environnements concernés devraient vérifier leurs pipelines CI/CD, leurs dépôts ainsi que la présence de fichiers .pth inattendus. Elles doivent également considérer les secrets identifiés comme potentiellement compromis, jusqu’à validation indépendante.

La simple suppression du paquet ne suffit pas à exclure toute persistance. Il faut également contrôler les hôtes sur lesquels le code a pu être exécuté et analyser les éventuelles publications, modifications de dépôts ou connexions inhabituelles ultérieures.

Le brief ne fournit aucune instruction officielle des éditeurs concernant la remédiation et ne confirme pas si la vulnérabilité ou la campagne ont été ajoutées au catalogue KEV de la CISA. Aucune date d’inscription au catalogue ni échéance fixée par la CISA n’est donc disponible.

La priorité opérationnelle reste la révocation et le remplacement des identifiants potentiellement exposés, ainsi que la révision des permissions accordées aux pipelines. En l’absence de confirmation complète de l’utilisation des secrets, la prudence impose de les traiter comme compromis.