Ars Technica rapporte une vaste fuite d’identifiants LiteLLM après une attaque de la chaîne d’approvisionnement

Ars Technica rapporte que des identifiants liés à plus de 2 500 organisations figuraient dans des données dérobées via un package d’IA compromis. L’ampleur rapportée transforme l’incident LiteLLM de mars, d’une brève défaillance de package, en une crise d’identifiants potentiellement durable.

Des attaquants ont corrompu deux versions officielles de LiteLLM et les ont distribuées via le Python Package Index, connu sous le nom de PyPI. Le code malveillant recherchait, sur les systèmes infectés, des clés cloud, des jetons de dépôt, des identifiants SSH, des mots de passe de bases de données et des secrets utilisés par des services d’IA.

L’attaque n’a pas commencé avec LiteLLM. Elle s’inscrivait dans une campagne qui s’est propagée à travers des outils de sécurité de confiance, des flux de travail de développeurs et des comptes de publication de packages. Chaque maillon compromis aurait fourni des identifiants permettant aux attaquants d’atteindre une autre partie de la chaîne d’approvisionnement logicielle.

Les données nouvellement rapportées offrent une image plus claire, mais encore incomplète, des conséquences. Des chercheurs ont relié des centaines de milliers de fichiers ou d’enregistrements de pipelines à plus de 2 500 organisations. Toutefois, l’apparition d’un domaine dans des données volées ne prouve pas que chaque organisation listée a subi un accès non autorisé.

Cette distinction est importante. La compromission confirmée du package a eu lieu en mars 2026, tandis que les chercheurs ont révélé l’ensemble de données plus vaste plusieurs mois plus tard. Les équipes de sécurité doivent désormais déterminer si les identifiants collectés pendant l’attaque étaient toujours valides, ont été utilisés de manière abusive ou ont été renouvelés avant que les attaquants puissent s’en servir.

Ce qu’Ars Technica indique que les données divulguées révèlent

La nouveauté n’est pas un autre package empoisonné, mais des éléments suggérant que l’intrusion initiale a dépassé de très loin les premières estimations.

Selon le rapport sur l’exposition d’identifiants, des chercheurs en sécurité ont examiné une vaste collection attribuée aux attaquants. Ce matériel contiendrait des secrets associés à plus de 2 500 organisations.

La collection comprenait des clés d’accès cloud, des jetons de dépôts source, des clés SSH, des secrets Kubernetes, des variables d’environnement, des identifiants de publication de packages et des clés de fournisseurs d’IA. Il s’agit d’identifiants opérationnels, et non de simples noms de comptes collectés dans un annuaire public.

Une clé cloud exposée peut donner accès à une infrastructure hébergée. Un jeton de dépôt peut révéler du code source privé ou autoriser des modifications non approuvées. Un identifiant de publication de package peut permettre à un attaquant de diffuser un logiciel malveillant sous le nom d’un projet de confiance.

Les secrets Kubernetes ouvrent une autre voie. Kubernetes est un système de gestion d’applications conteneurisées, et ses comptes de service peuvent disposer d’autorisations étendues sur l’infrastructure. Un jeton volé doté de droits excessifs peut aider un attaquant à passer d’une charge de travail à un cluster entier.

Les chercheurs ont également associé les données à environ 434 000 enregistrements d’intégration et de livraison continues. Les pipelines CI/CD automatisent les tests, la compilation et le déploiement de logiciels, souvent en chargeant temporairement des identifiants en mémoire.

Ce chiffre ne doit pas être interprété comme 434 000 compromissions confirmées. Une organisation peut exploiter de nombreuses tâches, exécuteurs, dépôts et exécutions répétées de pipelines. Des enregistrements en double peuvent aussi gonfler les comptes dans des données volées au cours de plusieurs étapes de campagne.

L’ensemble de données rapporté était lié à une collection de fichiers mesurant environ 195 To. Il serait trompeur de décrire chaque octet comme un identifiant unique. De telles collections peuvent inclure des fichiers système dupliqués, des arborescences source, des journaux, des archives et des captures mémoire, en plus des secrets.

La conclusion la plus défendable concerne l’étendue, et non le nombre d’identifiants. Les attaquants semblent avoir collecté des données dans de nombreux environnements de développement où des identifiants précieux étaient présents. La taille du matériel complique également la vérification et la notification des victimes.

CloudSEK a créé un service de vérification consultable qui permet aux organisations de contrôler si leurs domaines apparaissent dans le matériel analysé. Une correspondance doit déclencher une enquête, mais elle ne constitue pas une preuve concluante qu’un attaquant a pénétré le réseau de l’organisation.

De même, l’absence de correspondance ne devrait guère rassurer une organisation qui a installé un package affecté. Les ensembles de données peuvent être incomplets, les domaines peuvent être absents des artefacts machine, et l’infrastructure des attaquants peut échouer avant d’enregistrer une victime.

Le reportage accroît donc l’urgence de l’incident sans répondre à toutes les questions. Les organisations ont besoin de leurs propres historiques d’installation, de télémétrie réseau, de journaux d’audit cloud et d’historiques d’identifiants pour établir leur exposition réelle.

Un package d’IA de confiance est devenu le mécanisme de diffusion

LiteLLM était dangereux à compromettre parce qu’il fonctionne habituellement à proximité des identifiants mêmes que les attaquants cherchent à voler.

LiteLLM fournit une interface commune aux applications appelant différents services de grands modèles de langage. Au lieu de maintenir des intégrations distinctes, les développeurs peuvent acheminer les requêtes via un proxy ou une bibliothèque Python.

Cette commodité place LiteLLM à proximité des clés d’API pour OpenAI, Anthropic, les modèles hébergés dans le cloud et d’autres fournisseurs. Les déploiements de production peuvent également accéder à des bases de données, des plateformes d’observabilité, du stockage cloud et des services internes.

Des attaquants ont publié les versions malveillantes 1.82.7 et 1.82.8 de LiteLLM sur le véritable projet PyPI le 24 mars 2026. Il ne s’agissait pas de packages d’imitation aux noms mal orthographiés. Ils sont arrivés par le canal de distribution auquel les utilisateurs faisaient déjà confiance.

Wiz a indiqué que les versions sont apparues vers 8 h 30 UTC et que PyPI a mis le projet en quarantaine à 11 h 25 UTC. Son analyse du package malveillant a également constaté la présence de LiteLLM dans 36 % des environnements cloud observés par Wiz.

La version 1.82.7 activait sa charge utile lorsque le logiciel importait le code proxy LiteLLM ou démarrait le proxy. La version 1.82.8 ajoutait un fichier de démarrage Python nommé litellm_init.pth.

Python traite les fichiers .pth lors de l’initialisation de son environnement site-package. Par conséquent, le code malveillant pouvait s’exécuter à chaque démarrage de Python, même si une application n’importait jamais LiteLLM au cours de cette session.

Ce mécanisme a mis à mal une hypothèse courante sur l’exposition aux dépendances. Un développeur n’avait pas nécessairement besoin de lancer une commande manifestement compromise. L’installation de cette version pouvait placer un crochet d’exécution automatique dans l’environnement.

Le malware a ensuite recherché des informations dans la mémoire, les variables d’environnement, les répertoires de configuration, l’historique du shell et les emplacements habituels d’identifiants. Il chiffrait le matériel collecté avant de l’envoyer vers une infrastructure contrôlée par les attaquants et imitant le domaine légitime de LiteLLM.

Les cibles de données comprenaient apparemment des identifiants AWS, Google Cloud et Microsoft Azure. Le voleur recherchait également des jetons Kubernetes, de la configuration Docker, des mots de passe de bases de données, des portefeuilles de cryptomonnaies, des clés privées et des secrets CI/CD.

L’enquête de campagne de Datadog recommande de considérer tout système ayant installé les versions affectées comme une exposition complète d’identifiants. Cette position reflète le comportement de collecte du malware, et non la preuve que chaque secret découvert a atteint un attaquant.

Les responsables de LiteLLM ont déclaré que les versions compromises avaient été supprimées et que les identifiants des responsables avaient été renouvelés. Ils ont également indiqué que les utilisateurs de l’image Docker proxy n’étaient pas affectés, car leurs dépendances étaient verrouillées.

Les responsables ont fait appel à Mandiant et suspendu les versions pendant l’examen des dépôts et des systèmes de compilation. Leur réponse publique a relié la compromission de publication à des identifiants exposés lors de l’incident Trivy antérieur.

Ces mesures de confinement ont réduit les nouvelles infections. Elles ne pouvaient pas récupérer les données déjà transmises ni invalider automatiquement tous les identifiants volés. La remédiation devait donc aller bien au-delà de la désinstallation du package.

Le véritable adversaire est l’automatisation de confiance face à un accès limité

Cet incident oppose la rapidité de la livraison logicielle automatisée au principe de sécurité selon lequel aucune dépendance ne devrait hériter d’identifiants sans restriction.

Les pipelines de compilation modernes récupèrent du code, des outils, des conteneurs et des actions auprès de nombreux projets externes. L’automatisation rend les versions reproductibles, mais chaque dépendance devient une partie de la frontière de sécurité effective de l’organisation.

Trivy illustre le problème. C’est un scanner de sécurité utilisé pour détecter des vulnérabilités dans les conteneurs et les artefacts logiciels. Les équipes accordent souvent aux scanners une large visibilité, car l’inspection nécessite l’accès au code source, aux registres et aux sorties de compilation.

Le 19 mars, des attaquants ont compromis certaines parties de l’écosystème de versions et de GitHub Actions de Trivy. Datadog a indiqué que des composants malveillants récupéraient le contenu mémoire des exécuteurs hébergés par GitHub et recherchaient des emplacements d’identifiants courants.

Les attaquants semblent ensuite avoir réutilisé les accès volés sur d’autres projets et systèmes de packages. La campagne a atteint des actions et extensions liées à Checkmarx avant que des versions malveillantes de LiteLLM n’apparaissent sur PyPI.

Cette séquence renverse le modèle de sécurité habituel. Un scanner destiné à détecter des logiciels dangereux est devenu une source d’accès en amont ayant contribué à compromettre un autre package largement utilisé.

La campagne démontre également pourquoi le nom signé ou officiel d’un package ne peut pas trancher la question de la confiance. La présence authentique dans un registre confirme l’origine d’un artefact. Elle ne garantit pas que le compte de l’éditeur ou le pipeline de compilation soit resté sécurisé.

Les mises à niveau automatiques ont accru cette tension. Les équipes laissent souvent les correctifs s’appliquer rapidement, car elles s’attendent à ce que les petites versions contiennent des corrections compatibles. Les attaquants ont exploité cette attente en publiant des versions malveillantes via un projet légitime.

Le verrouillage des versions peut ralentir cette voie, mais ne constitue pas une défense complète. Une équipe peut approuver délibérément une version empoisonnée, surtout lorsque son identité de registre et son numéro de version paraissent normaux.

La vérification cryptographique de hachage offre un contrôle plus solide, car elle vérifie l’artefact exact. Toutefois, quelqu’un doit établir quel hachage est digne de confiance avant l’installation. Copier un hachage malveillant depuis le même canal compromis ne fait que préserver l’attaque.

Les miroirs privés de packages ajoutent une étape de révision et un délai avant que les artefacts externes atteignent la production. Ils créent aussi un autre service sensible qui doit être protégé, surveillé et maintenu à jour.

Le contrôle plus profond est l’isolation des identifiants. Une dépendance exécutée dans une tâche de compilation ne devrait recevoir que les autorisations nécessaires à cette tâche précise. Les identifiants de courte durée devraient expirer avant que des copies volées ne donnent un accès durable.

L’identité de charge de travail remplace les secrets statiques par des identifiants temporaires liés à une tâche ou à un service. Cette approche réduit la valeur des fichiers et variables d’environnement collectés depuis un exécuteur compromis.

Les organisations ont également besoin d’étapes de compilation distinctes. Une tâche d’analyse a rarement besoin d’autorisations pour publier des packages, administrer des comptes cloud, accéder à des bases de données de production et modifier des dépôts sans rapport.

De nombreux pipelines regroupent encore ces privilèges par commodité. Lorsqu’un processus peut atteindre tous les services de déploiement, une dépendance empoisonnée peut transformer une mise à jour logicielle en incident d’identité à l’échelle de l’organisation.

L’attaque LiteLLM n’a pas inventé cette faiblesse. Elle a révélé à quel point celle-ci s’aggrave lorsque le middleware d’IA se situe entre les applications, les fournisseurs de modèles, les clouds, les bases de données et les systèmes d’observabilité.

Pourquoi désinstaller LiteLLM ne suffisait pas

La suppression du package malveillant a arrêté une voie d’exécution, mais n’a pas révoqué les secrets copiés pendant que ce code était actif.

Le vol d’identifiants pose un problème de réponse distinct du nettoyage classique d’un malware. Reconstruire une machine peut éliminer une porte dérobée, mais l’attaquant peut toujours détenir des clés valides utilisables depuis un autre système.

Chaque environnement affecté nécessite un inventaire des identifiants. Les équipes de sécurité doivent déterminer quels secrets se trouvaient en mémoire, dans des fichiers, des variables d’environnement, des historiques de shell et des répertoires de comptes de service montés pendant la fenêtre d’exposition.

La rotation doit inclure les clés d’accès cloud, les clés de fournisseurs d’IA, les mots de passe de bases de données, les jetons de dépôt, les clés SSH, les comptes de service Kubernetes, les identifiants de registres de packages, les secrets de webhooks et les éléments de signature.

L’ordre est important. Les équipes doivent d’abord restreindre les accès suspects, préserver les preuves et créer des identités de remplacement. Elles peuvent ensuite mettre à jour les services dépendants avant d’invalider les identifiants exposés, sans provoquer de pannes incontrôlées.

Les journaux d’audit cloud peuvent révéler si des clés volées ont été utilisées depuis des emplacements inhabituels. Les historiques de dépôts peuvent montrer des clonages inattendus, la création de jetons, des modifications de workflows, des activités de publication ou des changements de permissions.

Les mainteneurs de packages ont une responsabilité supplémentaire. Si un jeton de publication était présent sur un runner infecté, chaque package accessible via ce jeton doit être examiné. Les attaquants peuvent attendre avant d’exploiter cet accès.

La technique de persistance .pth signifie également que les équipes doivent inspecter directement les environnements Python. Désinstaller LiteLLM ne supprime pas nécessairement un fichier de démarrage créé indépendamment dans site-packages.

La chronologie publique de l’incident recommande de vérifier la présence de litellm_init.pth et de faire tourner tous les identifiants présents sur les systèmes affectés. Elle identifie également le point de terminaison contrôlé par l’attaquant models.litellm.cloud.

Les défenseurs doivent rechercher dans les journaux réseau les connexions vers des infrastructures de commande connues. Ils doivent également examiner les enregistrements de processus, les démarrages Python inhabituels, la création d’archives et les pods Kubernetes privilégiés inattendus.

Toutefois, l’écoulement de plusieurs mois crée des lacunes de visibilité. Des périodes de conservation courtes peuvent effacer les enregistrements des terminaux et du réseau avant le début d’une enquête tardive.

Cette lacune explique pourquoi la divulgation de données signalée importe aujourd’hui. Une organisation n’ayant détecté aucune intrusion évidente en mars peut obtenir une nouvelle piste si son domaine apparaît dans les éléments récupérés.

Les enquêteurs doivent néanmoins éviter de traiter l’outil de recherche d’un chercheur comme une autorité définitive. Les correspondances de domaines peuvent provenir d’une configuration publique, de code source cloné, de références de fournisseurs ou de listes de clients.

L’erreur inverse est tout aussi risquée. Une entreprise ne doit pas écarter une correspondance simplement parce qu’elle ne peut pas immédiatement prouver une exfiltration. Les journaux d’identifiants, les enregistrements d’installation et les fichiers de verrouillage des dépendances peuvent fournir des preuves plus solides.

Les équipes doivent également inspecter les installations indirectes. Un développeur peut ne pas se souvenir d’avoir sélectionné LiteLLM parce qu’un autre framework, outil interne ou environnement de test a introduit le package.

Les nomenclatures logicielles aident à retracer ces relations. Une nomenclature répertorie les composants et versions inclus dans une application ou un artefact de build.

Pourtant, même une liste complète de composants ne peut révéler quels identifiants étaient visibles pendant l’exécution. Les preuves liées aux dépendances doivent être combinées aux enregistrements d’identité et d’accès à l’exécution.

Pour les développeurs qui doivent conserver des notes d’enquête, des chronologies d’identifiants et des décisions de remédiation, une base de connaissances technique consultable peut réduire la fragmentation des preuves. Les secrets sensibles eux-mêmes ne doivent jamais être copiés dans des notes générales.

Ce que les chiffres ne prouvent pas

L’ampleur signalée est alarmante, mais les éléments disponibles n’établissent pas 2 500 intrusions réseau abouties ni 195 To d’identifiants uniques.

Ars Technica attribue cette nouvelle ampleur à l’analyse de chercheurs en sécurité. La compromission sous-jacente du package est corroborée indépendamment par plusieurs enquêtes techniques et par la réponse des mainteneurs de LiteLLM.

Le nombre ultérieur de victimes dépend de la façon dont les chercheurs ont associé des artefacts volés à des organisations. Les informations publiques ne fournissent pas encore assez de détails pour reproduire chaque correspondance ou distinguer les clients, fournisseurs, développeurs et tiers mentionnés.

Un domaine d’entreprise peut apparaître dans du code source sans prouver que ce code provient du système du propriétaire du domaine. Des données de test, adresses e-mail, métadonnées de dépendances et documents peuvent tous contenir des noms externes.

Les chercheurs peuvent renforcer l’attribution à l’aide de plusieurs signaux. Ceux-ci incluent des noms d’hôtes internes, des chemins de dépôts privés, des identifiants de comptes cloud, des jetons propres à l’organisation, des noms de runners et des horodatages correspondants.

Même dans ce cas, « affectée » peut décrire plusieurs situations. Une organisation peut avoir exécuté le malware, une autre peut avoir exposé une clé révoquée, et une troisième peut seulement apparaître dans de la documentation copiée.

Le chiffre de 434 000 exige également du contexte. S’il représente des fichiers, des enregistrements ou des exécutions de pipeline, il ne doit pas être présenté comme un nombre équivalent de pipelines distincts compromis.

La collecte signalée de 195 To mérite une prudence similaire. Une archive brute de données volées peut contenir des répertoires répétés, de gros binaires, des fichiers de modèles, des caches, des dépôts source et des journaux.

Qualifier les 195 To d’« identifiants » efface ces distinctions au profit d’un titre spectaculaire. Les identifiants occupent peu d’espace, tandis que les environnements qui les entourent peuvent être immenses.

Le risque concret reste sérieux sans exagérer la formulation. Un petit fichier texte contenant une seule clé active d’administrateur cloud peut compter davantage que des téraoctets d’artefacts de build non sensibles.

Les organisations nommées doivent également être traitées équitablement. L’apparition dans un jeu de données d’exposition n’établit ni négligence, ni compromission continue, ni vol de données depuis leurs systèmes de production.

Certaines organisations répertoriées ont peut-être fait tourner leurs identifiants lors de la réponse initiale. D’autres ont pu fournir des noms ou domaines apparus dans l’environnement d’un fournisseur plutôt que dans le leur.

La possession et l’utilisation du jeu de données par les attaquants sont des questions distinctes. Les chercheurs auraient obtenu ou analysé des éléments liés à la campagne, mais les preuves publiques ne montrent pas dans quelle mesure chaque identifiant a été exploité.

La validité des identifiants change avec le temps. Les jetons temporaires peuvent expirer en quelques minutes, tandis que d’anciennes clés SSH et des identifiants API statiques peuvent rester fonctionnels pendant des mois ou des années.

L’incertitude la plus importante concerne les secrets à longue durée de vie. Si les organisations exposées n’ont fait tourner que les clés d’IA les plus évidentes, les attaquants pourraient conserver un accès via des jetons de déploiement ou comptes de service oubliés.

La divulgation doit donc être considérée comme une piste d’enquête étayée par un événement de malware confirmé. Elle ne doit pas devenir un verdict final de compromission pour chaque domaine du jeu de données.

Ce cadrage équilibré évite deux échecs. Il empêche un nombre de victimes exagéré de dépasser les preuves, et il empêche l’incertitude de devenir une excuse à l’inaction.

Trois signaux montreront si la crise est contenue

La prochaine phase dépend de la rotation des identifiants, de conclusions sur les victimes vérifiées indépendamment et de changements mesurables dans la sécurité de publication des packages.

Le premier signal est la preuve d’un abus d’identifiants après la fenêtre de confinement de mars. Les fournisseurs cloud, registres de packages et organisations affectées doivent indiquer si des identités volées ont permis des accès ultérieurs.

L’utilisation confirmée de jetons de publication dormants renforcerait l’idée que la campagne a créé une menace durable pour la chaîne d’approvisionnement. L’absence d’utilisation observée réduirait l’inquiétude immédiate, mais uniquement lorsque la couverture d’audit est adéquate.

Le deuxième signal est la validation indépendante du jeu de données d’exposition. Davantage d’organisations doivent comparer les correspondances des chercheurs avec les journaux d’installation, les identifiants cloud et la télémétrie réseau.

Des confirmations cohérentes étayeraient l’ampleur signalée. Des correspondances erronées généralisées ou des enregistrements en double réduiraient l’impact estimé sans remettre en cause la compromission confirmée de LiteLLM.

Le troisième signal est l’adoption de contrôles de publication et d’exécution plus sûrs. Le modèle de publication de confiance de PyPI utilise des jetons d’identité à courte durée de vie plutôt que des identifiants de téléversement réutilisables.

L’analyse plus large de la chaîne d’approvisionnement recommande la publication de confiance, la vérification des hachages d’artefacts, des comptes de service restreints et la surveillance des fichiers de démarrage Python inattendus. Le document identifie les middlewares d’IA comme un point de concentration des identifiants en aval.

Les développeurs ne doivent pas attendre une liste parfaite de victimes. Toute personne ayant installé LiteLLM 1.82.7 ou 1.82.8 doit considérer cet environnement comme exposé et vérifier que chaque identifiant accessible a été remplacé.

Les équipes de sécurité doivent également examiner l’exposition liée à Trivy à partir du 19 mars. La chaîne de la campagne a commencé avant l’apparition des versions malveillantes de LiteLLM, et se concentrer sur un seul package peut faire manquer la compromission en amont.

Les organisations ne trouvant aucune version affectée doivent tout de même examiner leur politique de dépendances. Le prochain package empoisonné n’utilisera pas nécessairement LiteLLM, Python ou le même mécanisme de persistance.

La leçon centrale du rapport d’Ars Technica est plus précise et plus actionnable que ne le suggèrent ses chiffres énormes. Une automatisation de confiance a placé des identités précieuses à côté de code tiers, et une chaîne compromise a atteint de nombreux systèmes.

Posez-vous une question concrète aujourd’hui : quel package externe peut lire vos identifiants de build les plus privilégiés ? Si la réponse n’est pas claire, cartographiez cet accès avant que la prochaine mise à jour de routine ne transforme une confiance cachée en incident.