Les dépendances d’IA attaquées : ce que la compromission de LiteLLM enseigne aux développeurs

Une équipe de développement installe un paquet depuis le registre officiel. Le paquet porte le nom, la version et l’éditeur attendus. Il est passé par le processus de publication habituel du projet, avec une provenance qui indique comment il a été construit.

Ce sont des signaux de confiance significatifs. Mais ils ne permettent pas d’établir que personne ayant autorité sur la publication n’a modifié le code en cours de construction.

Le 21 octobre 2026, le processus de publication normal de LiteLLM a distribué la version malveillante 1.107.0 sur PyPI et sur ses registres de conteneurs officiels. L’enquête menée ensuite par LiteLLM a décrit comment un attaquant a obtenu de puissants identifiants GitHub, modifié un workflow de publication privé et l’a orienté vers la construction de code issu d’un dépôt imitant l’original. Des chercheurs indépendants ont examiné le paquet malveillant et y ont trouvé des mécanismes de collecte d’identifiants déclenchés au démarrage de Python. (enquête de LiteLLM sur l’incident, analyse de la charge utile par Microsoft et analyse indépendante de Datadog)

L’incident offre une leçon pratique aux développeurs qui utilisent des passerelles d’IA et d’autres logiciels tiers. Vérifier d’où vient un paquet est important. Ce n’est pas la même chose que savoir que le code qu’il contient est digne de confiance.

La publication semblait légitime parce que le processus l’était

LiteLLM fournit un logiciel que les applications peuvent utiliser pour se connecter à différents fournisseurs de modèles de langage. À cette place, il peut manipuler des clés d’API et d’autres éléments de configuration importants. Il est aussi installé dans des environnements de développement et des builds automatisés.

Selon l’enquête de LiteLLM du 23 octobre, l’attaque a commencé bien avant l’apparition de la version malveillante. En mai, une clé d’administration d’une Agent Platform interne expérimentale a été commitée dans un dépôt public. Le fichier a été supprimé au bout de plusieurs heures, mais la clé est restée valide. LiteLLM a indiqué qu’un attaquant l’a utilisée le 10 octobre pour accéder à l’Agent Platform et obtenir un jeton OAuth de GitHub CLI associé à un propriétaire de l’organisation. (enquête publiée par LiteLLM)

Ce détail compte, car un secret divulgué n’est pas forcément inoffensif une fois son fichier supprimé. Si le secret reste valide, le système qui l’accepte peut toujours accorder un accès. L’étendue de cet accès détermine jusqu’où une compromission peut se propager.

LiteLLM a indiqué que l’attaquant a utilisé le jeton de niveau propriétaire pour exécuter des workflows qui ont exposé d’autres secrets. Le 21 octobre, l’attaquant a modifié un workflow de publication privé pour qu’il accepte un propriétaire de dépôt source configurable. Une règle de protection de branche normale a rejeté un premier push. L’identifiant de propriétaire de l’organisation a malgré tout permis à la modification de passer. (enquête publiée par LiteLLM)

Le workflow modifié a ensuite construit le code depuis Berri-AI/litellm, un dépôt imitant l’original, au lieu de la source légitime BerriAI/litellm. Selon LiteLLM, le jeton volé d’un second mainteneur a approuvé le point de contrôle de publication en production, tandis que l’identifiant de propriétaire de l’organisation a lancé le déclenchement en préproduction (staging dispatch). Les artefacts obtenus ont atteint les canaux de distribution officiels par l’infrastructure de publication attendue. (enquête de LiteLLM et analyse de Datadog)

L’enquête indépendante de Microsoft sur la charge utile corrobore le récit d’une publication compromise, mais précise explicitement qu’elle n’a pas déterminé de façon indépendante comment l’accès initial en amont et le vol d’identifiants se sont produits. Cette partie de la séquence doit donc être comprise comme une conclusion forensique rapportée par LiteLLM. (Microsoft Security Research)

Selon la chronologie de LiteLLM, la version malveillante a été mise en ligne vers 11 h 39 UTC le 21 octobre. Une issue publique a signalé un problème vers 12 h 06, PyPI a mis la version en quarantaine vers 13 h 23 et les registres de conteneurs ont suivi vers 13 h 51, une fenêtre que LiteLLM décrit comme d’environ deux heures. Datadog situe la quarantaine sur PyPI vers 13 h 20 et le retrait des images de conteneurs vers 13 h 53, soit également environ deux heures, et ne donne aucune heure de détection. Les deux récits divergent de quelques minutes, pas sur l’ensemble. (enquête publiée par LiteLLM et analyse de Datadog)

Une voie de publication fiable ne garantit pas un code source fiable

Il est utile de distinguer trois questions.

L’authenticité consiste à savoir si un artefact provient de l’éditeur attendu. La provenance décrit le processus et la source enregistrée qui l’ont produit. La fiabilité du code consiste à savoir si le logiciel obtenu peut être exécuté sans danger.

Ces propriétés sont liées, mais elles ne sont pas interchangeables.

Un enregistrement de build ou une attestation de provenance peut identifier le workflow et le dépôt source utilisés pour créer un artefact, sans établir si cette source était autorisée ou sûre. Dans l’incident LiteLLM, l’attaquant a influencé la source que le workflow légitime a construite. Datadog a indiqué que les artefacts publiés portaient une provenance de build apparemment légitime, qui désignait fidèlement le fork malveillant comme leur source. (Datadog Security Labs)

Ce n’est pas une raison d’abandonner la signature, la vérification de provenance ou Trusted Publishing. Ces contrôles peuvent aider à vérifier l’origine d’un artefact ou à réduire la dépendance à des identifiants d’éditeur de longue durée. Ils ne déterminent pas à eux seuls si une identité d’éditeur privilégiée a été compromise ni si le build a sélectionné la source prévue. Le suivi publié par LiteLLM le 30 octobre indique que son propre pipeline a signé les artefacts et qu’ils portaient une provenance Trusted Publishing valide. (suivi de LiteLLM)

Pour une équipe de développement, cette distinction change la façon d’évaluer une dépendance. La confiance ne s’arrête pas au registre de paquets. Elle dépend aussi des identités des éditeurs, des dépôts sources approuvés, des permissions de build et de l’environnement dans lequel le paquet s’exécute.

Pourquoi installer ce paquet pouvait suffire

La version malveillante de LiteLLM ne reposait pas sur un développeur posant la mauvaise question à un modèle d’IA. Elle exploitait le comportement ordinaire de Python au démarrage.

Microsoft et Datadog ont trouvé trois fichiers malveillants livrés par la wheel concernée : cook.pth, cook.py et sitecustomize.py. Python peut traiter certaines instructions .pth et charger sitecustomize pendant l’initialisation de l’interpréteur. Dans un environnement touché, le simple démarrage de Python pouvait activer du code malveillant, même si l’application n’importait jamais LiteLLM. (analyse de Microsoft et analyse de Datadog)

L’exposition potentielle s’étendait donc au-delà des systèmes utilisant activement LiteLLM comme passerelle. Un ordinateur portable de développeur, un conteneur de test ou un agent de build pouvait exécuter Python pour une tâche sans rapport après l’installation du paquet compromis.

La charge utile récupérée ciblait les identifiants cloud accessibles, les identifiants de développeur et de gestion de code source, les clés de fournisseurs d’IA, les données de navigateur, les éléments SSH et certains enregistrements de la base de données de LiteLLM. Elle comportait aussi un mécanisme capable de récupérer du code supplémentaire. Les chercheurs n’ont pas observé la livraison d’une seconde étape, même si Microsoft a noté que le chargeur pouvait être réarmé. (analyse de Microsoft et analyse de Datadog)

Cibler un identifiant ne prouve pas que l’attaquant l’a obtenu. L’impact sur un environnement donné dépend des fichiers et des identités qui étaient accessibles, du fait que la charge utile s’est exécutée assez longtemps, que la transmission a réussi et que les identifiants étaient encore valides.

Cette distinction devrait guider à la fois les comptes rendus de sécurité et la réponse aux incidents. La version concernée était dangereuse. Il ne s’ensuit pas que chaque téléchargement a causé une violation confirmée.

Pourquoi supprimer le paquet peut ne pas suffire à rétablir la confiance

Les fichiers de démarrage malveillants pouvaient être installés en dehors du répertoire applicatif ordinaire de LiteLLM. Supprimer ce seul répertoire pouvait laisser l’environnement Python en mesure d’exécuter de nouveau la charge utile. Microsoft comme Datadog ont mis en garde contre le fait de considérer la désinstallation normale du paquet comme une remise en état complète. (analyse de Microsoft et analyse de Datadog)

Il existe aussi un piège pratique pendant l’investigation. Lancer le Python ou le pip de l’environnement touché pour l’inspecter peut déclencher le même comportement au démarrage. Les équipes qui examinent une machine potentiellement compromise devraient utiliser des outils sains et un processus isolé plutôt que d’exécuter l’environnement suspect.

Pour les organisations qui ont pu installer la version 1.107.0, la réponse devrait s’appuyer sur les avis de sécurité qui font autorité et sur leur propre équipe de sécurité. Identifiez les hôtes, postes de travail, conteneurs et environnements de build concernés. Isolez ou reconstruisez les environnements suspects, recherchez d’éventuelles traces d’exécution et d’activité sortante, et, depuis un environnement sain, renouvelez les identifiants auxquels le processus compromis pouvait accéder. Examinez les journaux d’audit pertinents pour détecter tout usage abusif ultérieur. (analyse de Microsoft et analyse de Datadog)

Une reconstruction et une revue des identifiants peuvent demander plus de travail que la suppression d’un paquet. Ce travail traite le risque réel, qui ne se limite pas à la présence persistante de LiteLLM lui-même.

Ce que cet incident change pour les développeurs

La leçon immédiate consiste à rendre la confiance accordée aux dépendances plus précise.

Pour les équipes qui consomment des paquets, l’épinglage des versions et des mises à jour de dépendances maîtrisées réduisent l’exposition imprévue. Ils ne rendent pas sûre une version malveillante épinglée. L’analyse des paquets et les vérifications de provenance apportent des éléments utiles, mais l’équipe a toujours besoin d’un moyen d’identifier rapidement les déploiements touchés, de reconstruire les environnements et de renouveler les identifiants auxquels ces environnements ont accès.

Pour les équipes qui publient des logiciels, le choix de la source doit être encadré indépendamment de l’autorisation de lancer une publication. Les workflows de publication ne devraient pas pouvoir construire à partir de n’importe quel dépôt imitant l’original simplement parce qu’un compte privilégié fournit un paramètre. Les identifiants d’éditeur, les comptes de niveau propriétaire et les secrets de CI devraient avoir la portée et la durée de vie minimales nécessaires. Lorsqu’une clé divulguée est découverte, la retirer du gestionnaire de code source doit être suivi de sa révocation et d’une évaluation de l’exposition.

Pour les équipes plateforme et sécurité, la question la plus importante est souvent de savoir jusqu’où une dépendance compromise peut aller. Une passerelle d’IA peut côtoyer des clés de fournisseurs, des identifiants de charges de travail cloud et des accès à des bases de données. Ces permissions devraient être bornées, afin que la compromission d’un processus n’expose pas automatiquement l’infrastructure plus large d’une organisation.

Aucune de ces mesures ne garantit l’immunité. Ensemble, elles réduisent les chances qu’une seule publication compromise se transforme en incident plus large touchant les identités et l’infrastructure.

En quoi cela diffère d’une attaque contre un serveur d’IA en fonctionnement

L’article distinct de TechiesJournal sur PoeLLM (en anglais) examine des attaquants qui exploitent des services d’IA et de développement vulnérables, dont une faille d’autorisation MCP de LiteLLM. Il s’agit d’un problème d’exposition à l’exécution : un attaquant atteint un logiciel déjà déployé.

L’incident du 21 octobre a franchi une autre frontière. Le code malveillant est arrivé par le processus de livraison logicielle lui-même. Une équipe pouvait installer la version compromise depuis une source officielle sans avoir d’abord exposé un point de terminaison public vulnérable.

Cette distinction compte au moment de décider quoi inspecter. Le durcissement à l’exécution et les correctifs traitent les faiblesses des services exposés. La provenance des dépendances, les restrictions sur les sources, l’identité des éditeurs, l’isolation des identifiants et la préparation à la remise en état traitent d’autres aspects du risque lié à la chaîne d’approvisionnement logicielle. Les organisations ont besoin des deux.

Question	Attaque contre un serveur d’IA en fonctionnement	Publication compromise
Comment le code malveillant arrive	Un attaquant atteint un logiciel déjà déployé.	Il arrive par le processus de livraison logicielle lui-même.
Ce qu’une équipe pouvait faire pour être exposée	Faire tourner un point de terminaison public vulnérable.	Installer la version compromise depuis une source officielle.
Ce qu’il faut inspecter	Durcissement à l’exécution et correctifs.	Provenance des dépendances, restrictions sur les sources, identité des éditeurs, isolation des identifiants et préparation à la remise en état.

Ce qu’une publication digne de confiance peut et ne peut pas vous apprendre

Un processus de publication légitime a de la valeur, et l’incident d’octobre n’y change rien. Il montre qu’un processus de publication hérite de la sécurité des identités et des sources auxquelles il fait confiance.

Les développeurs devraient continuer à utiliser les canaux officiels, des mises à jour maîtrisées, une provenance vérifiée et des signatures lorsque c’est pris en charge. Ils devraient aussi savoir ce que chaque signal prouve. Un enregistrement de publication authentique peut identifier le processus de publication sans dire si l’autorité qui contrôle ce processus a été compromise.

L’étape pratique suivante n’est pas de se méfier de chaque outil d’IA. Elle consiste à examiner où s’exécutent les dépendances d’IA, à quels identifiants elles ont accès, comment leurs mises à jour sont approuvées et à quelle vitesse une version compromise peut être retirée sans laisser l’environnement ni ses secrets exposés.

Pour aller plus loin

1. LiteLLM: The attack chain behind the v1.107.0 LiteLLM release (23 octobre 2026). Enquête des mainteneurs sur la chaîne d’identifiants, la manipulation du workflow et la chronologie de la publication.
2. Microsoft Security Research: Inside the LiteLLM 1.107.0 supply chain compromise (23 octobre 2026). Recherche indépendante sur l’exécution au démarrage de Python, la collecte d’identifiants et la réponse.
3. Datadog Security Labs, LiteLLM supply chain compromise: What you need to know (21 octobre 2026). Analyse indépendante des artefacts, tags de distribution et recommandations de remédiation.
4. LiteLLM: What we are changing after October 21 (30 octobre 2026). Suivi des mainteneurs sur la signature et les contrôles de sécurité prévus. Ces contrôles sont des projets, pas des travaux achevés.