Le pipeline de publication de LiteLLM a été compromis le 21 octobre 2026, permettant à un attaquant de publier une version malveillante de ce logiciel de passerelle IA sur PyPI, Docker Hub et GitHub Container Registry.
La version concernée, LiteLLM v1.107.0, a collecté identifiants et autres secrets sur les systèmes où elle s'exécutait, selon les conclusions d'Aikido et de Wiz relayées par The Hacker News. Wiz a ensuite observé des tentatives de validation d'identifiants AWS volés, provenant de runners CI et de nœuds Kubernetes compromis.
LiteLLM a divulgué l'incident dans un avis publié mercredi. L'entreprise situe l'intrusion vers 4 h 00 (heure du Pacifique) le 21 octobre 2026.
Quels paquets et tags de conteneurs étaient touchés
Les artefacts compromis comprenaient :
- le paquet PyPI LiteLLM v1.107.0 ;
- le tag Docker/GHCR v1.107.0 ;
- le tag Docker/GHCR latest ;
- le tag Docker/GHCR main-latest ;
- le tag Docker/GHCR main-stable.
Pour PyPI, la fenêtre d'exposition signalée concerne les utilisateurs ayant installé avec pip un paquet LiteLLM sans version figée, entre 11 h 39 et 13 h 23 UTC.
Pour les conteneurs, la fenêtre d'exposition va de 11 h 46 à 14 h 20 UTC pour les utilisateurs ayant téléchargé ou utilisé d'une autre manière les images listées. Plusieurs tags étant mutables, la seule vérification du tag configuré dans un déploiement ne permet pas forcément de savoir quelle image a réellement été exécutée. Les équipes défensives doivent donc vérifier l'artefact ou l'image exact utilisé.
Des jetons GitHub volés ont permis une version empoisonnée
Selon le compte rendu de LiteLLM, l'attaquant avait accès à trois jeux d'identifiants de l'interface GitHub CLI appartenant à des développeurs. Le premier pouvait déclencher des workflows GitHub, tandis qu'un jeton appartenant à un propriétaire d'organisation a servi à désactiver les protections de branches et à pousser de force des modifications malveillantes.
Le workflow compromis a été détourné du dépôt légitime BerriAI/litellm vers un dépôt au nom trompeusement proche, Berri-AI/litellm. Cette substitution a permis aux paquets et images malveillants de passer par le processus de signature et de publication du projet.
Deux jours plus tôt, le 19 octobre 2026, LiteLLM avait temporairement élargi les droits de publication de deux ingénieurs internes, chargés de produire chaque jour des rétroportages de correctifs pour les clients.
L'entreprise soupçonne que les jetons GitHub ont pu être exposés via les journaux d'un déploiement interne accessible depuis Internet, où elle a découvert un compte au nom anodin et inattendu. LiteLLM indique que Claude Code peut placer le jeton OAuth de l'interface GitHub CLI d'un utilisateur dans le corps d'une réponse. Si ces corps de réponse sont enregistrés, le jeton peut donc apparaître dans les journaux de LiteLLM. L'entreprise présente cette piste comme une hypothèse, et non comme un point d'entrée initial établi.
LiteLLM affirme avoir ajouté des protections supplémentaires pour les publications après un incident distinct survenu en mars 2026 : déplacement des publications vers un dépôt privé, tags Docker de publication rendus immuables et signature des images de conteneurs. Lors de la compromission d'octobre, l'attaquant a néanmoins pu manipuler le workflow chargé de produire et de publier les artefacts signés.
Le logiciel malveillant a collecté des secrets et maintenu une porte dérobée horaire
Aikido et Wiz décrivent deux mécanismes d'exécution Python intégrés à la version compromise.
Le premier utilise cook.pth, qui importe un module Python nommé cook. Le script correspondant, cook.py, se désobfusque et lance une routine de vol d'identifiants appelée privcollect.
Ce voleur cible les secrets associés à :
- des systèmes d'exploitation ;
- des navigateurs web ;
- des outils de développement ;
- des environnements cloud ;
- des outils d'IA.
Les informations collectées sont envoyées par une requête HTTP POST vers :
litellm[.]dev/healthcheck
Sous Linux et macOS, un second composant nommé sitecustomize.py tente de récupérer domain.txt depuis une boîte aux lettres morte (dead drop) GitHub associée à github[.]com/letters9813. Une réponse valide fournit l'adresse à partir de laquelle le logiciel peut télécharger et exécuter un script Python de second niveau, situé à <domain>/codepy.
Le composant lance également un processus en arrière-plan, crée le fichier de verrouillage /tmp/remote_code_loader.lock et entre dans une boucle qui vérifie la boîte aux lettres toutes les heures, avant de tenter à nouveau d'exécuter la charge distante. Aikido qualifie ce mécanisme de cheval de Troie d'accès à distance.
Wiz indique que GitHub a supprimé le fichier texte servant de boîte aux lettres vers 13 h 30 UTC. Selon les informations disponibles, ce fichier ne contenait, avant sa suppression, que des valeurs de test initiales.
Les identifiants AWS ont été testés quelques heures après leur exfiltration
Wiz indique que l'exploitation a commencé environ 4,5 heures après l'exfiltration des identifiants. Entre 16 h 20 et 17 h 01 UTC, le 21 octobre 2026, l'attaquant a testé des identifiants de rôle d'instance AWS obtenus à partir de runners CI et de nœuds Kubernetes.
Chaque identifiant a été vérifié à l'aide de :
sts:GetCallerIdentitybedrock:ListFoundationModels- un appel
ListModels
Wiz juge cette activité compatible avec le LLMjacking, qui consiste à tester des identifiants cloud volés pour accéder à des services d'IA hébergés. Dans un petit nombre d'environnements, l'attaquant a également mené une reconnaissance IAM et d'infrastructure à l'aide d'opérations telles que ListRoles, ListUsers, ListAccessKeys, ListAccounts et DescribeTrails.
Le trafic de validation des identifiants est associé à :
168.100.8[.]57
165.227.201[.]8
Bien que l'utilisation d'un fichier .pth ressemble à l'attaque de mars 2026 attribuée, selon les articles, à TeamPCP, Socket n'a trouvé aucune preuve publique établissant que les deux incidents avaient le même opérateur. Socket relève des différences dans les clés publiques RSA intégrées, le code d'exfiltration et le comportement de la porte dérobée. L'entreprise précise aussi que les éléments disponibles ne permettent pas de déterminer si des identifiants volés en mars ont contribué à la compromission d'octobre.
Que doivent faire aujourd'hui les utilisateurs de LiteLLM
Les organisations qui ont installé ou exécuté LiteLLM 1.107.0, y compris via les tags de conteneurs concernés, doivent considérer comme potentiellement compromis l'hôte et les identifiants accessibles à ce processus.
Parmi les actions recommandées figurent :
- Supprimer LiteLLM 1.107.0 des machines et des environnements de déploiement.
- Isoler les hôtes touchés pendant l'analyse des accès du paquet.
- Rechercher :
cook.pthcook.pysitecustomize.py/tmp/remote_code_loader.lock
- Bloquer et examiner les connexions vers :
litellm[.]dev/healthcheckgithub[.]com/letters9813raw[.]githubusercontent[.]com/letters9813/pythonclient-test/main/domain[.]txt
- Examiner toute tentative ou exécution réussie de
/codepy. - Analyser les journaux AWS à la recherche d'activité liée aux adresses IP signalées et aux appels d'API.
- Révoquer et renouveler chaque identifiant accessible depuis un environnement touché, y compris les secrets cloud, de développement, de navigateur et des services d'IA.
- Reconstruire les systèmes touchés à partir d'artefacts de confiance, plutôt que de se limiter à la suppression des fichiers malveillants.
Le chercheur Guy Korolevski, de JFrog, conseille également de vérifier le fichier wheel exact installé et de contrôler les versions des paquets avant leur intégration dans les systèmes de build. Lorsque la version 1.107.0 a été exécutée, JFrog recommande de renouveler tous les identifiants auxquels elle a pu accéder et de reconstruire l'environnement concerné.
