Une attaque éclair de 40 minutes aux conséquences durables

Le 24 mars 2026, deux versions piratées de LiteLLM — un gateway IA open source largement utilisé pour connecter des applications à plusieurs fournisseurs de modèles — sont restées disponibles sur PyPI pendant environ 40 minutes, entre 10h39 et 11h25 UTC. Le temps d'exposition paraît dérisoire, mais les conséquences s'étalent sur des mois. Ce 12 août 2026, la société de renseignement sur les menaces CloudSEK révèle qu'elle a obtenu un dataset constitué d'environ 434 000 fichiers capturés par les attaquants, cartographiant une exposition potentielle touchant plus de 2 500 organisations, parmi lesquelles NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens ou encore X Corp.

Précision essentielle : ce chiffre n'est pas un compte de victimes. CloudSEK le précise explicitement auprès de The Hacker News : le matériel provient de sources de renseignement confidentielles et se compose de fichiers et de logs d'exfiltration évalués comme appartenant à la campagne, et non de données récoltées auprès des organisations nommées. Le dataset est publié sous forme de table de recherche publique, consultable par nom ou domaine, avec filtrage par niveau de confiance (High ou Medium).

La chaîne d'attaque TeamPCP, du scanner Trivy à LiteLLM

L'incident LiteLLM ne se comprend qu'en remontant à la campagne de compromission de chaîne d'approvisionnement baptisée TeamPCP (que Google suit sous le nom d'UNC6780). Tout commence avec Trivy, le scanner de sécurité d'Aqua Security.

Le 19 mars 2026, un acteur malveillant utilisant des identifiants compromis a publié une version Trivy v0.69.4 malveillante, forcé la réécriture de 76 des 77 tags de version de aquasecurity/trivy-action vers des commits contenant un voleur d'identifiants, et remplacé les 7 tags de aquasecurity/setup-trivy par des commits malveillants. L'attaque est enregistrée sous la référence CVE-2026-33634, ajoutée au catalogue des vulnérabilités exploitées (KEV) de la CISA le 26 mars 2026.

D'après l'avis de sécurité publié par Aqua Security sur GitHub, cet incident est la continuité d'une compromission initiale remontant à fin février 2026. Après une première divulgation le 1er mars, une rotation d'identifiants a bien été effectuée — mais de manière non atomique. Les attaquants auraient pu utiliser des jetons encore valides pendant la fenêtre de rotation (qui a duré plusieurs jours) pour exfiltrer de nouveaux secrets fraîchement régénérés et conserver leur accès.

Le 22 mars, des images Docker malveillantes Trivy v0.69.5 et v0.69.6 ont également été publiées sur Docker Hub via des identifiants Docker Hub distincts compromis. Le 23 mars, c'est l'action GitHub KICS de Checkmarx qui a été compromise à son tour, avec un mode opératoire identique : mêmes conventions de nommage, même clé publique RSA-4096, comme l'a documenté Wiz.

Comment LiteLLM a été empoisonné

Les versions 1.82.7 et 1.82.8 de LiteLLM, publiées directement sur PyPI le 24 mars, contenaient un voleur d'identifiants sophistiqué. D'après le rapport d'incident officiel de LiteLLM :

  • v1.82.7 : charge utile malveillante intégrée dans litellm/proxy/proxy_server.py, déclenchée à l'import de litellm.proxy.
  • v1.82.8 : ajout d'un fichier litellm_init.pth (34 628 octets) qui, comme tout fichier .pth placé dans site-packages, est exécuté par Python au démarrage de l'interpréteur — même si LiteLLM n'est jamais importé. Le projet précise qu'une dépendance transitive non épinglée, par exemple via un framework d'agents IA ou un outil d'orchestration, pouvait installer cette version sans que personne ne l'ait explicitement choisie.

La charge malveillante collectait :

  • les variables d'environnement (dont OPENAI_API_KEY et ANTHROPIC_API_KEY)
  • les clés SSH et configurations Git
  • les identifiants cloud (AWS, GCP, Azure)
  • les jetons Kubernetes et configurations de service account
  • les mots de passe de bases de données
  • les portefeuilles de cryptomonnaies
  • les clés privées SSL, historiques shell, configurations CI/CD

Les données étaient ensuite chiffrées (AES-256-CBC avec une clé de session aléatoire, elle-même chiffrée par une clé publique RSA-4096 codée en dur) puis exfiltrées via un POST HTTP vers models.litellm[.]cloud — un domaine enregistré le 23 mars 2026 via Spaceship, Inc., soit quelques heures avant l'apparition des paquets malveillants, et sans aucun lien avec le projet LiteLLM.

L'analyse technique très détaillée publiée par FutureSearch et le blog rosesecurity.dev révèle des détails supplémentaires : un mécanisme de persistance Kubernetes créait des pods privilégiés dans le namespace kube-system, tandis qu'un backdoor Python était installé sur ~/.config/sysmon/sysmon.py avec un service systemd. Un canal d'exfiltration de secours utilisait le GITHUB_TOKEN disponible pour créer un dépôt public nommé tpcp-docs et y téléverser les données volées sous forme d'asset de release.

Un récit disputé sur le mode d'infection

La manière exacte dont les versions malveillantes ont atteint PyPI fait l'objet de récits divergents :

  • CloudSEK affirme qu'un build empoisonné a produit et publié les releases.
  • LiteLLM, dans son propre rapport d'incident et dans l'issue GitHub #24518, indique qu'un upload direct sur PyPI a contourné le workflow CI/CD officiel, suggérant la compromission du compte PyPI d'un mainteneur (krrishdholakia).
  • Unit 42 décrit des attaquants ciblant les jetons de publication PyPI après la brèche Trivy.

Interrogée par The Hacker News, CloudSEK a balayé la contradiction : « Ce sont différentes étapes de la même chaîne d'attaque, pas des explications concurrentes. » L'avis de la PyPA décrit d'ailleurs la même séquence : un jeton d'API exposé via la dépendance Trivy compromise, puis utilisé pour téléverser les deux versions.

Le dataset CloudSEK : méthode et limites

L'attribution dans le dataset repose sur deux vérifications indépendantes. Un premier index assigne chaque fichier à partir des variables d'identité du runner CI (identité de l'hôte, domaines des contributeurs légitimes). Une seconde « porte de propriété » redérive l'appartenance à partir des logs récupérés et peut surcharger la première assignation. « Si les deux sont en désaccord, le rapport est retenu », indique CloudSEK, et le verdict final prend le niveau de confiance le plus bas.

Le chiffre de 434 000 fichiers compte des fichiers capturés et des événements d'exfiltration plutôt que des pipelines ou des jobs distincts. CloudSEK précise qu'un fichier capturé correspond approximativement à une exécution de job, mais ne présente pas le total comme des jobs uniques sans déduplication et vérification indépendantes. La société n'a pas souhaité commenter les notifications pré-publication adressées aux organisations nommées, ni indiquer si l'une d'entre elles a contesté son inclusion.

Des victimes confirmées au-delà des statistiques

Même si les chiffres de CloudSEK restent des estimations d'exposition, l'impact réel de la campagne est avéré :

  • Checkmarx a reconnu que des identifiants obtenus via l'attaque Trivy ont permis un accès non autorisé à ses dépôts GitHub et la publication d'artefacts malveillants (compromission de l'action KICS et des extensions OpenVSX).
  • Mercor a indiqué avoir été affecté par les versions malveillantes de LiteLLM et avoir contenu une activité non autorisée.
  • CERT-EU a évalué avec un haut niveau de confiance qu'un compte AWS de la Commission européenne a été compromis via l'attaque Trivy, avec environ 91,7 Go de données compressées exfiltrées.

Le FBI exhorte à la rotation des secrets

Dans une notice FLASH du 2 juillet 2026 (FLASH-20260702-01), le FBI a averti que les acteurs affiliés sont susceptibles d'exploiter les identifiants exfiltrés pendant la campagne TeamPCP longtemps après la compromission initiale. Un secret à longue durée de vie copéré pendant la fenêtre d'exposition — une clé cloud statique, une clé SSH, un jeton de publication — reste utilisable tant qu'il n'a pas été révoqué. Le Bureau recommande la rotation de tous les secrets CI/CD, jetons de publication et identifiants cloud accessibles pendant les fenêtres d'exposition pertinentes, et invite à privilégier les jetons temporaires (OIDC, short-lived credentials) plutôt que les jetons à longue durée de vie.

L'ampleur de la contamination

La fiche NVD de CVE-2026-33634 liste désormais plusieurs composants affectés au-delà de Trivy et LiteLLM :

Composant Versions affectées
Trivy (Go/image) = 0.69.4
trivy-action (GitHub Action) 0.0.1 – 0.34.2
setup-trivy (GitHub Action) 0.2.0 – 0.2.5
BerriAI LiteLLM 1.82.7 – 1.82.8
team-telnyx/telnyx (Python) 4.87.1 – 4.87.2
KICS GitHub Action (Checkmarx) toutes les tags jusqu'au 23 mars
Extensions OpenVSX Checkmarx cx-dev-assist 1.7.0, ast-results 2.53.0

Les images Docker malveillantes Trivy v0.69.5 et v0.69.6, publiées le 22 mars sur Docker Hub, ont également été compromises via des identifiants Docker Hub séparés.

Que doivent faire les organisations concernées ?

Trois étapes prioritaires sont recommandées par l'ensemble des sources consultées :

  1. Vérifier l'exposition : rechercher toute installation de LiteLLM 1.82.7 ou 1.82.8 pendant la fenêtre d'audit du 24 mars 2026 (10h39 à 16h00 UTC). LiteLLM fournit des scripts de scan pour GitHub Actions et GitLab CI. Pour Trivy, vérifier les logs de workflow des 19–20 mars 2026, en recherchant notamment la ligne révélatrice Terminate orphan process: pid (...) (curl).

  2. Pivoter tous les secrets : tout identifiant présent sur les systèmes affectés doit être considéré comme compromis — clés SSH, identifiants cloud, jetons Kubernetes, mots de passe de bases de données, clés API de modèles (OpenAI, Anthropic, etc.).

  3. Rechercher les artefacts d'exfiltration : fouiller les organisations GitHub à la recherche de dépôts nommés tpcp-docs ou docs-tpcp. Le préfixe tpcp-docs- peut varier et les releases sont taguées data-<timestamp>, une recherche par nom exact peut donc échouer.

Des leçons structurelles

L'incident illustre plusieurs fragilités structurelles de l'écosystème open source : la mutabilité des tags Git (qui ne sont que des pointeurs déplaçables à volonté), la dangerosité des dépendances transitives non épinglées, et le risque d'une rotation d'identifiants non atomique laissant des fenêtres d'accès aux attaquants. LiteLLM a depuis reconstruit son pipeline CI/CD (« CI/CD v2 ») avec environnements isolés, portes de sécurité renforcées et signatures cosign pour ses images Docker. Aqua Security a activé les releases immuables de GitHub.

Mais au-delà des corrections techniques, le message de CloudSEK et du FBI est clair : les secrets volés en mars 2026 restent une monnaie d'échange active pour les attaquants. La rotation ne doit pas attendre la preuve d'une exploitation — elle est la réponse par défaut.