LiteLLM attaque supply chain du 21 octobre 2026

LiteLLM attaque supply chain, le 21 octobre 2026, a publié la version 1.107.0 avec un malware sur PyPI et dans des images Docker. LiteLLM est une passerelle Python qui unifie les fournisseurs de modèles de langage. Le paquet tourne souvent près des clés cloud et LLM.

Si votre équipe a installé cette version ou a tiré des tags flottants officiels dans la mauvaise fenêtre, le risque ne se limite pas au paquet. En outre, la charge utile entre dans l’environnement Python et peut s’exécuter à chaque démarrage de l’interpréteur, même sans importer LiteLLM. La priorité est donc de contenir, nettoyer les hooks, reconstruire et faire tourner les secrets accessibles.

Ce guide reste sur l’angle défense et développement. Vous repartez ainsi avec la fenêtre en UTC et un périmètre clair. Ensuite, vous voyez comment prouver l’exposition et ce qu’il faut faire tourner. Après cela, vous fixez la litellm 1.106.2 version sûre et vous séparez ce qui reste en enquête.

Que s’est-il passé et quelle a été la fenêtre UTC ?#

Le 21 octobre 2026, la chaîne de publication de LiteLLM a été compromise, et la version 1.107.0 est sortie avec un voleur d’identifiants et un chargeur de code distant. L’artefact dangereux a atteint PyPI et des images officielles. LiteLLM 1.107.0 malveillant n’était donc pas un simple bug de code dans la balise Git propre.

Quelle a été la fenêtre UTC sur PyPI et Docker ?#

Selon l’avis officiel de l’incident, mis à jour le 21 octobre 2026 à 20 h 30 UTC, le paquet litellm==1.107.0 est resté en ligne sur PyPI environ deux heures. La fenêtre PyPI allait de 11 h 39 UTC à 13 h 23 UTC. Les images Docker Hub v1.107.0, latest, main-latest et main-stable ont pointé vers l’index compromis de 11 h 46 UTC à 14 h 20 UTC.

Le digest cité dans l’avis pour l’image mauvaise sur Docker Hub est sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. Sur GHCR, les tags équivalents ont été compromis à partir de 11 h 46 UTC. Ensuite, ils sont devenus indisponibles jusqu’à environ 13 h 51 UTC. La balise de code v1.107.0 du dépôt légitime ne portait pas les fichiers malveillants. Les artefacts sont donc partis d’un dépôt contrôlé par l’attaquant.

Pourquoi la balise Git propre ne suffisait-elle pas ?#

L’analyse de JFrog Security Research confirme que les sept wheels de la 1.107.0 transportaient la charge utile. En revanche, l’archive source ne portait pas les trois mêmes fichiers de démarrage. Quiconque ne regarde que la balise Git ou le sdist peut donc croire la release propre. Pourtant, la mauvaise wheel peut encore entrer sur l’hôte. The Register a décrit le même jour une distribution de malware de vol de secrets et d’un RAT via PyPI et les registres Docker.

En pratique, ce que je vois le plus souvent, c’est une équipe qui traite « deux heures en ligne » comme une fenêtre trop courte pour inventorier. Or, avec un cache CI, un rebuild automatique et un pull de latest, cette fenêtre suffit à contaminer un runner, un notebook et un proxy. L’horloge utile reste l’UTC de l’installateur et du registre, et non le fuseau du bureau.

Qui est concerné sur PyPI, Docker, et qui fixe une version ?#

Vous entrez dans le périmètre si vous avez installé litellm==1.107.0 dans l’intervalle PyPI. Vous y entrez aussi si vous avez exécuté une image v1.107.0, latest, main-latest ou main-stable dans l’intervalle Docker. Qui épingle une ancienne version et n’a pas tiré la 1.107.0 dans cette fenêtre reste hors de l’artefact mauvais. Même ainsi, il faut encore valider lockfiles, caches et images locales.

L’avis officiel sépare les utilisateurs open source des clients enterprise sur le registre privé. En OSS, un pip sans pin ou une image à tag flottant dans la fenêtre doit être traité comme compromis. Côté enterprise, LiteLLM affirme que le registre privé utilisé pour la distribution sous embargo n’a pas été touché. Cela ne vaut que si l’installation venait vraiment de ce canal privé. Sinon, le PyPI public et les tags publics de Docker Hub ou de GHCR portent le même risque.

Qui « fixe une version » au quotidien change aussi l’exposition. Dependabot, Renovate, une image de base sans digest et pip install -U litellm sans hash élargissent la chance d’attraper la 1.107.0. De plus, personne n’a besoin de remarquer le numéro tout de suite. Datadog Security Labs résume la surface en paquet PyPI et tags GHCR et Docker Hub. L’article rappelle aussi le volume élevé de téléchargements hebdomadaires, ce qui explique l’urgence d’inventaire même avec peu d’heures d’exposition.

L’erreur qui coûte le plus cher ici, c’est d’assumer que « nous n’utilisons pas Docker, donc nous sommes tranquilles », ou l’inverse. LiteLLM PyPI compromis et LiteLLM Docker supply chain sont des vecteurs parallèles de la même release. L’inventaire doit donc croiser lockfile, historique pip, digest d’image et horodatage UTC du job.

Comment savoir si vous avez installé la version mauvaise ?#

Commencez par l’historique d’installation et par le digest, et non par le ressenti de l’équipe. Si pip show litellm a déjà indiqué 1.107.0 à un moment de la fenêtre, l’environnement doit être traité comme compromis. Il en va de même si le conteneur a exécuté le digest compromis. Cela reste vrai même si le paquet a déjà disparu de l’index public.

Cherchez des preuves de litellm-1.107.0.dist-info et de wheels 1.107.0 en cache. Cherchez aussi des builds qui ont installé la version sans pin entre 11 h 39 UTC et 13 h 23 UTC le 21 octobre 2026. Dans les conteneurs, comparez le digest tiré avec sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. Trouver l’un de ces signaux confirme l’exposition. Ne rien trouver, toutefois, ne nettoie pas l’environnement, car le ménage de /tmp, un rebuild et une rotation de volumes effacent des traces.

Socket a enregistré que son scanner a marqué les wheels quelques minutes après la publication. En outre, la provenance de l’image pointait le dépôt lookalike Berri-AI/litellm, et non le BerriAI/litellm légitime. Cela aide à expliquer pourquoi la balise source « officielle » peut sembler propre alors que l’artefact installable ne l’était pas. Si votre pipeline ne valide que la balise Git, il pouvait passer au vert et livrer quand même LiteLLM 1.107.0 malveillant.

Beaucoup pensent que désinstaller le paquet efface le problème, et ils se trompent presque toujours, parce que les hooks sont partis à la racine de site-packages. La vérification de version doit donc aller avec la chasse à cook.pth, cook.py et un sitecustomize.py inattendu. Sans ces deux axes, vous ne fermez que la moitié de l’inventaire.

Quels indicateurs de compromission l’avis officiel et les analyses listent-ils ?#

Les IoC les plus utiles aujourd’hui mêlent fichiers de démarrage, artefacts sous /tmp, domaine d’exfiltration et digest d’image. L’avis officiel demande de chercher litellm-1.107.0.dist-info, cook.pth et sitecustomize.py. Il oriente aussi à tuer le démon Python qui tient /tmp/remote_code_loader.lock avant tout pip dans l’environnement sale.

JFrog publie une liste opérationnelle alignée sur ce tableau. Parmi les signaux figurent le domaine www.litellm.dev et le chemin /healthcheck. Apparaissent aussi le dead-drop raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt, le marqueur /tmp/.pc_once_72129118c59f5636c0bb, les artefacts /tmp/.pc_sq_ et /tmp/.pc_e_, ainsi que le digest de l’image touchée. Selon The Register, le chasseur d’Aikido a aussi souligné /tmp/.pc_once_* comme signal d’exfiltration déjà déclenchée. Le lock du loader, de son côté, pointe un C2 actif ou récent.

Le mécanisme compte pour la chasse. cook.pth force l’import de cook.py au démarrage de Python. sitecustomize.py lance le loader en arrière-plan. Ainsi, tout python, pip ou job dans le venv peut retrigger le malware. En réponse à incident, le premier réflexe faux est d’ouvrir le venv et de « juste lancer un pip show ». Si l’interpréteur sale monte, vous pouvez réexécuter la charge utile pendant le diagnostic.

Préférez des outils shell et filesystem qui n’invoquent pas ce Python. Isolez la machine et préservez les journaux DNS, proxy et cloud avant un nettoyage agressif. L’absence du lock sur un hôte ne prouve pas l’absence de vol d'identifiants LiteLLM, car un conteneur éphémère et un ménage de /tmp retirent la preuve avec facilité.

LiteLLM attaque supply chain impose de faire tourner quels secrets ?#

Si la 1.107.0 a tourné sur un hôte avec sortie Internet, l’avis officiel demande d’assumer qu’une exfiltration a pu avoir lieu. Le marqueur d’exécution unique confirme quand il existe. L’absence du marqueur n’innocente pas, car conteneur éphémère et ménage de /tmp retirent la preuve.

La liste minimale du communiqué officiel inclut le rôle IAM de l’instance ou de la tâche. Elle inclut aussi toutes les clés de fournisseur stockées dans la base du proxy LiteLLM, la master key et les virtual keys, le mot de passe de DATABASE_URL et tout secret présent dans l’environnement des processus sur cet hôte. Ensuite, LiteLLM recommande de regarder CloudTrail pour GetCallerIdentity du rôle à l’heure de l’installation et pour l’usage de ce matériel hors de votre infrastructure. Pour le flux AWS, organiser d’abord l’ordre des journaux aide à ne pas confondre symptôme et cause.

Les analyses de Wiz et de JFrog élargissent l’inventaire au-delà du proxy. Elles décrivent la collecte d’identifiants de navigateur, AWS, Azure et GCP, de tokens et configs d’outils d’IA, de clés SSH et GPG, de secrets CI et de variables d’environnement lisibles. Wiz parle de modules larges de collecte dans le navigateur, le cloud et les services d’IA. Traitez cela comme une hypothèse forte de surface, et non comme la preuve que chaque module a tiré chez vous. La rotation doit pourtant couvrir tout ce que l’hôte pouvait atteindre, car le coût de laisser une clé vivante dépasse souvent celui de tourner tôt.

Quand l’environnement semble « seulement un bac à sable de prompt », le risque change peu s’il y avait une vraie clé de fournisseur, un token cloud ou un volume monté avec ~/.aws. Faites tourner, révoquez et régénérez. Auditez ensuite l’usage. Nettoyer un fichier sans faire tourner le secret laisse la porte ouverte à qui a déjà reçu le paquet chiffré.

Comment fixer la version et vérifier le hash ou la signature ?#

La version sûre pointée de façon cohérente par l’avis officiel, JFrog, Endor Labs et The Register est la 1.106.2. Pourtant, le pin correct n’est pas la première commande. Si l’environnement a déjà exécuté la 1.107.0, commencer par pip install sur le même Python peut réarmer cook.pth et sitecustomize.py.

Pourquoi ne pas commencer par pip install ?#

Endor Labs insiste sur le fait que l’attaque vit dans l’empaquetage. La balise revue, à elle seule, ne montre pas le changement de build. Toute commande qui monte le Python sale peut donc réarmer les hooks. Diagnostic et remédiation doivent commencer hors de cet interpréteur.

Ordre défensif de confinement et de pin#

Suivez cet ordre défensif, adapté du communiqué officiel et des notes de JFrog.

1. Isolez l’hôte ou le conteneur et préservez les journaux réseau, DNS, endpoint et cloud avant d’effacer une preuve utile.
2. Retirez cook.pth, cook.py, sitecustomize.py et les *.pyc correspondants dans __pycache__ de chaque site-packages touché, avec des outils qui ne démarrent pas le Python compromis.
3. Arrêtez le processus détaché lié à /tmp/remote_code_loader.lock et inspectez les marqueurs /tmp/.pc_once_, /tmp/.pc_sq_ et /tmp/.pc_e_*.
4. Reconstruisez le venv ou l’image depuis zéro et épinglez litellm==1.106.2, de préférence avec le hash de la bonne wheel et un digest immuable de la bonne image.
5. Ce n’est qu’alors que vous faites tourner les secrets accessibles et que vous auditez l’usage ultérieur de ces secrets.

Vérifier hash et signature réduit la récidive, mais ne remplace pas le rebuild. Socket a montré que la provenance du build peut enregistrer une source lookalike presque légitime. Un pin par numéro sans pin par hash laisse donc de la place à un artefact échangé au prochain incident. Contrôler digest d’image, hash de wheel et origine du dépôt doit devenir une habitude de release, et non un rituel réservé à l’après-choc.

Le raccourci qui retarde le plus le confinement, c’est de « corriger sur place » et de continuer avec le même volume sale. Reconstruire depuis un artefact vérifié coûte du temps maintenant et évite un faux négatif cher ensuite. S’il y a un doute entre nettoyer et recréer, recréer gagne dans la plupart des proxies et runners d’IA.

Open source et enterprise diffèrent-ils dans cet incident ?#

Oui, et la différence vient du canal de distribution, non d’une immunité magique. LiteLLM affirme que les clients sur le registre privé enterprise n’ont pas été impactés par cette release publique 1.107.0. Qui tirait du PyPI public ou des tags publics de Docker Hub et GHCR entre dans le scénario OSS décrit dans l’avis.

Il y a un détail supplémentaire dans le communiqué lui-même. L’entreprise mentionne une release sous embargo sur le canal privé liée à une vulnérabilité dont la divulgation était prévue pour le 27 octobre 2026. Cela est indépendant du malware de la 1.107.0 et ne doit pas se lire comme « enterprise est déjà patché pour tout ». Cela signifie seulement que le registre privé n’a pas été le canal de l’artefact trojanisé de cet incident, selon la source officielle.

Datadog observe aussi que c’est la deuxième compromission supply chain de LiteLLM en 2026. Au moment de leur analyse, aucun lien établi n’existait avec l’épisode précédent qu’ils associent à l’activité TeamPCP. Sans source primaire nouvelle attribuant un acteur nommé à ce cas du 21 octobre 2026, un texte défensif doit parler d’attaquant et de dépôt lookalike, selon le consensus des sources ouvertes, et non d’un groupe précis.

En opération mixte, le risque pratique est que l’équipe enterprise croie « nous sommes clients, donc c’est fini » alors qu’un job parallèle installe encore depuis PyPI. Confirmez le registre réel de chaque environnement. Si un seul cluster boit aux deux mondes, l’exemption du canal privé ne couvre pas le nœud qui a bu à la source publique.

Comment réduire le risque supply chain sur les dépendances d’IA ?#

Après le confinement, le gain est de rendre le prochain échange d’artefact plus cher pour l’attaquant et plus visible pour vous. Pin de version exacte, pin de hash en Python, digest immuable d’image et interdiction de latest en production forment le plancher. Au-dessus, bloquez les tags flottants dans la CI d’une passerelle LLM et exigez une revue humaine quand le lockfile monte la version d’un proxy qui garde des clés.

Surveillez l’egress vers des domaines lookalike et vers des dead-drops sur raw GitHub. Dans ce cas, le domaine d’exfiltration cité par les analyses techniques était une variation proche de la marque. Traitez aussi les hooks de démarrage dans site-packages comme surface de persistance. Une chasse à la persistance pour blue team s’applique quand la charge utile survit à la suppression du paquet principal. Pour le processus continu, un programme de gestion des vulnérabilités doit inclure les dépendances d’IA avec la même rigueur qu’une lib web classique.

Jusqu’à la mise à jour officielle du 21 octobre 2026 à 20 h 30 UTC, LiteLLM disait avoir identifié la chaîne d’attaque avec un haut degré de confiance, alors que l’enquête restait en cours. Le récit officiel et les analyses techniques ouvertes décrivent des artefacts construits depuis le dépôt lookalike Berri-AI/litellm, et non depuis la balise propre du projet légitime. Dans les sources ouvertes retenues ici, il n’y a pas non plus de CVE classique pour un « bug de code » de la 1.107.0, car le cœur du dossier est un artefact trojanisé dans la chaîne de distribution.

Il y a une limite claire. Aucune de ces mesures n’élimine la supply chain. Elles réduisent la fenêtre, augmentent la chance de détection et diminuuent le rayon d’impact quand un token de release fuit. Séparer les environnements qui gardent des clés de fournisseur, utiliser des secrets de courte durée et éviter un notebook avec un rôle trop large restent une défense réelle, même avec un scanner de paquets dans le pipeline.

L’habitude qui différencie le plus une équipe mature d’une équipe pressée, c’est de refuser un rebuild « rapide » avec un tag mobile après l’incident. Si la correction d’hier a utilisé latest, la prochaine 1.10x.y mauvaise peut entrer par la même porte. La discipline d’artefact est ennuyeuse, et c’est exactement ce que ce cas a sanctionné.

Questions fréquentes sur LiteLLM attaque supply chain#

Cette section répond à des doutes réels de qui opère un proxy LLM, une CI et des notebooks le jour même de l’incident. Les réponses ci-dessous partent de l’avis LiteLLM du 21 octobre 2026 et des analyses techniques ouvertes de JFrog, Datadog, Socket, Wiz, Endor Labs et The Register. Elles ne remplacent pas une forensique de votre environnement, car cache, volume et heure de pull changent le cadrage de chaque hôte.

Faut-il faire tourner les clés si j’ai seulement testé l’image puis supprimé le conteneur ?#

Oui, si le conteneur avec l’image mauvaise a bien démarré et avait une sortie réseau ou un montage avec des secrets, la rotation reste nécessaire. Supprimer le conteneur retire le système de fichiers éphémère, mais n’invalide pas un matériel déjà exfiltré. L’avis officiel demande explicitement d’assumer l’exfiltration lorsque la 1.107.0 a tourné avec Internet. Faites tourner les clés de fournisseur, les secrets d’environnement et les identifiants cloud accessibles, puis auditez tout usage hors de la fenêtre légitime.

La balise Git propre de la 1.107.0 signifie-t-elle que je peux faire confiance à la release ?#

Non. L’avis officiel et Socket montrent que la balise source légitime ne contenait pas les fichiers malveillants, alors que wheels et images ont été construites depuis un dépôt lookalike. Se fier seulement à la balise Git ou au sdist était exactement l’angle mort de ce dossier. Pour l’installation, ce qui compte est la wheel ou le digest réellement téléchargé par l’environnement, avec hash et origine vérifiés.

Désinstaller litellm avec pip retire-t-il déjà le malware ?#

Dans bien des cas, cela ne suffit pas comme premier pas, et cela peut être dangereux si la commande monte le Python sale. Les fichiers cook.pth, cook.py et sitecustomize.py vivent à la racine de site-packages et se déclenchent au démarrage. L’orientation convergente est de retirer ces hooks sans invoquer l’interpréteur touché, abattre le loader, reconstruire l’environnement et seulement ensuite installer la 1.106.2 épinglée. Traitez un uninstall isolé comme incomplet jusqu’à preuve d’absence des hooks et des artefacts sous /tmp.

Les clients enterprise sont-ils automatiquement en sécurité ?#

Seulement si l’installation venait du registre privé que LiteLLM déclare non touché. Si un environnement enterprise tirait aussi le PyPI public ou les tags publics latest, main-stable ou main-latest dans la fenêtre du 21 octobre 2026, cet environnement entre dans le même playbook que l’OSS. La question utile n’est pas le contrat commercial. C’est l’URL et le digest réels de l’artefact dans chaque cluster.

Quelle est la différence pratique entre ce cas et un CVE de code ?#

Ici, le problème central est la supply chain de l’artefact publié, et non un bug documenté avec un CVSS dans le code de la balise propre. Les actions immédiates tournent donc autour de l’inventaire de version, du digest, des hooks de démarrage et de la rotation de secrets. Même sans CVE classique publié dans les sources retenues, l’impact opérationnel peut être élevé, car la charge utile s’exécute tôt et vise les identifiants cloud et LLM sur le même hôte.

Conclusion#

Si votre environnement a touché la 1.107.0 dans la fenêtre du 21 octobre 2026, l’ordre qui protège le mieux la plupart des équipes est d’isoler, retirer les hooks sans réarmer Python, reconstruire avec litellm==1.106.2 épinglée par hash ou digest, faire tourner tout ce que l’hôte pouvait atteindre et auditer l’usage des clés. Attendre un rapport parfait avant l’inventaire ne fait qu’allonger le temps où une credential vivante reste utile à qui a déjà collecté le paquet.

La réponse change lorsque vous prouvez, avec origine et horodatage, que vous n’avez jamais installé la mauvaise wheel et jamais tiré les tags flottants dans la fenêtre Docker. Dans ce cas, il vaut encore durcir pin et surveillance, mais le confinement forensique cesse d’être le centre. Le premier pas concret maintenant est de lister hôtes, runners et proxies avec LiteLLM et de marquer ceux qui sont passés par pip ou pull entre 11 h 39 UTC et 14 h 20 UTC ce jour-là.

Ce texte a un caractère informatif et éducatif sur LiteLLM attaque supply chain du 21 octobre 2026. Il ne remplace ni une évaluation professionnelle de sécurité, ni une réponse à incident, ni une forensique dans votre environnement précis.