Cinq mois après LiteLLM : votre PME sait-elle quels outils IA elle exécute ?

Oui, il vous faut un inventaire de vos outils IA et une règle de validation avant tout déploiement, même sans RSSI et même à dix personnes. Le 24 mars 2026, deux versions piégées de LiteLLM publiées sur PyPI ont pu exfiltrer les secrets des machines qui les installaient ; cinq mois plus tard, les estimations disponibles ne permettent toujours pas de compter les PME françaises touchées, mais elles suffisent à imposer une décision : savoir quels composants IA tournent chez vous, avec quelles clés et quels accès.

Cet article n'est pas un récit d'attaque de plus. Il sépare ce que l'éditeur confirme, ce que les sociétés de renseignement sur les menaces estiment et ce qui reste inconnu. Ce qui nous intéresse est l'après : les comptages publiés en août 2026 par CloudSEK et Hudson Rock, la vulnérabilité distincte ajoutée au catalogue KEV de la CISA en juin, et surtout la décision qu'un dirigeant de PME peut prendre cette semaine sans équipe de sécurité dédiée.

« The compromised PyPI packages were litellm==1.82.7 and litellm==1.82.8. Those packages were live on March 24, 2026 from 10:39 UTC for about 40 minutes before being quarantined by PyPI. »

Avis de sécurité officiel de LiteLLM, mis à jour le 27 mars 2026.

L'essentiel en quatre points

• Le 24 mars 2026, deux versions malveillantes de LiteLLM, 1.82.7 et 1.82.8, ont été publiées sur PyPI. LiteLLM attribue probablement l'origine de la compromission à son usage de Trivy dans la chaîne CI/CD, mais présente encore ce vecteur comme le résultat d'une investigation et non comme une certitude judiciaire.
• Le paquet est téléchargé environ 3,4 millions de fois par jour selon Snyk, et il entre dans les projets par dépendance transitive : vous pouvez l'avoir installé sans jamais avoir entendu son nom.
• En août 2026, CloudSEK a estimé que plus de 2 500 organisations et environ 434 000 pipelines CI/CD, c'est-à-dire des chaînes automatisées de construction et de déploiement, pouvaient être exposés ; Hudson Rock dit avoir attribué 118 829 vidages de runners CI à 2 488 domaines. Ces métriques de fournisseurs ne sont ni un décompte officiel des victimes ni une mesure des PME françaises.
• La parade tient en deux gestes à la portée d'une PME : un inventaire des outils IA réellement installés, et une règle de validation avant déploiement. Les deux tiennent sur une page.

Que s'est-il passé le 24 mars 2026 ?

La mécanique probable est un cas d'école d'attaque en cascade. Le 19 mars 2026, TeamPCP compromet la GitHub Action de Trivy, un scanner de vulnérabilités, comme le détaille l'enquête d'Akamai sur la campagne TeamPCP. LiteLLM utilisait Trivy dans son pipeline de publication. Dans son avis officiel, l'équipe écrit qu'elle pense que la compromission provient de cet usage et que les éléments disponibles suggèrent aussi une compromission du compte PyPI du mainteneur. C'est l'hypothèse de travail la mieux étayée, pas une chaîne causale définitivement établie. Hudson Rock propose une reconstitution plus affirmative ; nous la conservons comme analyse de fournisseur, sans la confondre avec la position officielle.

Le mardi 24 mars à 10 h 39 UTC, les versions 1.82.7 puis 1.82.8 arrivent sur PyPI. C'est un développeur, Callum McMahon, qui donne l'alerte à 11 h 48 après avoir repéré un comportement anormal, raconte Numerama dans sa reconstitution du 25 mars 2026. Sur la durée d'exposition, les sources divergent : l'avis officiel LiteLLM parle d'environ 40 minutes avant la mise en quarantaine par PyPI, tandis que l'analyse technique de Snyk évalue la fenêtre à environ trois heures entre publication et retrait effectif. Quelle que soit la borne retenue, le point décisif est ailleurs : LiteLLM est téléchargé environ 3,4 millions de fois par jour selon Snyk, donc même une fenêtre d'une heure représente un volume considérable d'installations automatiques, la plupart par des machines, sans qu'aucun humain ne regarde ce qui s'installe.

La charge utile était d'une redoutable économie. La version 1.82.8 embarquait un fichier (litellm_init.pth), un mécanisme légitime de Python qui s'exécute au démarrage de l'interpréteur, que la victime importe explicitement la bibliothèque ou non. Selon l'avis officiel LiteLLM, le code malveillant balayait les variables d'environnement, les clés SSH, les identifiants cloud AWS, GCP et Azure, les jetons Kubernetes et les mots de passe de bases de données, puis exfiltrait le tout vers un domaine imitant celui de l'éditeur. Hudson Rock ajoute que la charge, en trois étapes, tentait des mouvements latéraux dans les clusters Kubernetes et installait une porte dérobée persistante.

Pourquoi cette brèche vous concerne, même si vous ne connaissiez pas LiteLLM

La première objection du dirigeant de PME est prévisible : nous ne faisons pas de Python, ce paquet ne nous regarde pas. C'est précisément le piège. LiteLLM est une passerelle qui unifie l'accès à de nombreux services d'IA derrière une seule API, et l'avis officiel liste explicitement parmi les victimes potentielles les projets où LiteLLM arrive comme dépendance transitive, par exemple via des frameworks d'agents IA, des serveurs MCP ou des outils qui coordonnent plusieurs modèles. Autrement dit, l'outil de prospection, le prototype d'assistant interne ou le connecteur no-code qu'un collaborateur a installés en mars peuvent l'avoir tiré sans jamais l'afficher.

L'ampleur réelle n'a été mesurée qu'en août 2026, quand deux sociétés de renseignement sur les menaces ont publié leurs comptages. CloudSEK, le 11 août 2026, estime à plus de 2 500 organisations et environ 434 000 pipelines CI/CD l'exposition potentielle, et qualifie l'incident de plus grande attaque supply chain visant l'infrastructure IA recensée en 2026. Le lendemain, Hudson Rock révélait avoir obtenu l'archive brute des données exfiltrées : 153 Go, exactement 433 909 fichiers, dont ses chercheurs ont attribué 118 829 vidages de runners CI à 2 488 domaines d'entreprise, dont de grands noms français comme Orange. Le détail qui devrait retenir l'attention des petites structures : Hudson Rock signale qu'une grande partie des secrets volés n'est pas attribuable, car les pipelines génériques ne contiennent ni email d'entreprise ni nom de serveur interne. Des organisations ont donc des identifiants actifs dans cette archive sans le savoir, et la taille n'y change rien.

Ce que les chiffres prouvent, et ce qu'ils ne prouvent pas

Trois niveaux de preuve coexistent. Le premier est officiel : LiteLLM confirme les deux versions compromises, leur présence sur PyPI et le comportement de collecte de secrets. Le deuxième vient de fournisseurs de threat intelligence : CloudSEK mesure une exposition potentielle, tandis que Hudson Rock dit analyser une archive exfiltrée et attribuer une partie des fichiers à des domaines. Le troisième reste inconnu : le nombre d'organisations réellement compromises, le nombre de secrets encore valides et la part des PME françaises. Additionner les chiffres des deux fournisseurs serait une erreur, car ils ne décrivent ni la même unité ni le même protocole.

La décision ne dépend donc pas d'un faux total. Même si votre entreprise ne figure dans aucun décompte public, elle reste exposée à la même classe de risque dès qu'un composant tiers peut lire des secrets au moment de l'installation ou du démarrage. L'inventaire proposé plus bas ne sert pas à déclarer une compromission ; il sert à savoir où chercher, quoi révoquer et qui décide lorsqu'une alerte apparaît.

Cinq mois après, qu'est-ce qui a changé dans votre PME ?

C'est ici que l'article bascule du récit vers la décision. Opinion de Pierre Beunardeau : une PME ne devrait pas attendre de savoir si son domaine apparaît dans une archive pour cartographier ses outils IA. Le mécanisme de mars montre que l'organisation n'avait pas besoin d'être visée : l'installation automatique d'une dépendance suffisait. La bonne réponse n'est donc pas une statistique de plus, mais une responsabilité nommée et un registre maintenu.

Et le dossier n'est pas clos. Le 8 juin 2026, la CISA américaine a inscrit la CVE (identifiant public d'une vulnérabilité) 2026-42271 à son catalogue des vulnérabilités activement exploitées. L'avis NVD décrit une injection de commande dans deux points d'entrée de test MCP, touchant les versions 1.74.2 à antérieures à 1.83.7, avec correction en 1.83.7. Il s'agit d'une vulnérabilité distincte de la compromission PyPI de mars. Celui qui avait « géré mars » en mettant à jour une fois devait encore suivre le composant en juin. La leçon n'est pas de cesser d'utiliser ces outils : c'est qu'on ne gère pas ce qu'on n'a pas recensé.

Ce que nous câblons dans nos propres agents en production illustre la même discipline côté défense : chaque outil branché est déclaré, chaque accès borné, chaque action sensible validée. Notre article sur l'architecture de sécurité d'un agent connecté à la base clients montre comment cette approche se traduit concrètement, avec une couche de politique entre l'agent et les données.

La checklist d'inventaire express, une heure sans RSSI

L'inventaire n'est pas un audit de sécurité. C'est une liste honnête, tenue par une personne nommée, qui répond à trois questions : quels outils IA tournent chez nous, quelles clés leur avons-nous confiées, à quelles données peuvent-ils toucher. Une heure suffit pour une première version dans une PME de moins de cinquante personnes.

1. Recenser les outils IA réellement utilisés : abonnements SaaS, assistants installés en local, plugins de navigateur, scripts et prototypes internes, intégrations branchées sur le CRM ou la messagerie. Interroger les équipes, pas seulement la comptabilité : les outils gratuits ne laissent pas de facture.
2. Pour chaque outil, noter qui l'a installé, quelles clés API ou identifiants il détient, et où ces secrets vivent : fichier de configuration (.env), gestionnaire de mots de passe, variable d'environnement sur un poste ou un serveur.
3. Noter les accès effectifs : quelles données l'outil lit-il, quels systèmes peut-il modifier, les permissions sont-elles limitées au strict nécessaire.
4. Marquer les dépendances cachées : un outil no-code qui « appelle OpenAI » a une chaîne de fournisseurs ; demander au fournisseur comment il gère ses propres dépendances fait partie de l'inventaire.
5. Fixer la règle de validation : aucun nouvel outil IA ne se branche sur des données ou des clés de l'entreprise sans une validation courte, consignée, par une personne désignée.

Avant de refermer la page, contrôlez chaque point :

• ☐ Chaque outil IA connu a un propriétaire nommé dans l'entreprise.
• ☐ Chaque clé API est recensée, datée, et on sait comment la révoquer.
• ☐ Les permissions de chaque outil sont limitées aux données strictement nécessaires.
• ☐ La règle de validation avant déploiement est écrite et tient en moins de dix lignes.
• ☐ Une date de revue est fixée, et l'inventaire sera refait à chaque nouvel outil.

Ce registre est volontairement indépendant d'un produit de sécurité. Une feuille de calcul suffit au départ, à condition qu'elle ait un propriétaire, une date et un rituel de mise à jour. Le détail technique peut vivre ailleurs ; la page de pilotage doit permettre à un dirigeant de répondre immédiatement : quel outil couper, quelle clé révoquer, qui appeler et quelles données considérer comme exposées.

Cas appliqué : une PME de 30 personnes fait son inventaire

Appliquons la checklist à une entreprise fictive de services, 30 personnes, sans informaticien dédié. Ce scénario est une construction pédagogique, pas un résultat client.

La dirigeante délègue l'inventaire à son office manager, qui y consacre une matinée. Premier tri : douze outils IA recensés, dont quatre que la direction ne connaissait pas, un plugin de rédaction installé par un commercial, un prototype d'assistant de devis bricolé par un stagiaire en mars, un connecteur de transcription, un outil de génération de visuels. Deuxième tri : les clés. Le prototype du stagiaire appelle une API avec la clé personnelle d'un salarié, stockée dans un fichier texte sur le serveur partagé. Le connecteur de transcription détient un accès complet au drive de l'entreprise alors qu'il n'a besoin que d'un dossier. Troisième tri : la chaîne cachée. L'outil de devis s'appuie sur un framework d'agents qui, en mars, dépendait de LiteLLM ; impossible de savoir rétroactivement quelle version tournait le 24 mars, donc la clé concernée est immédiatement révoquée et régénérée.

Le lendemain, l'entreprise adopte sa règle de validation : tout nouvel outil IA est annoncé au responsable nommé, qui vérifie trois choses, clé dédiée, permissions bornées, fournisseur identifié, avant le premier branchement sur des données réelles. Le tout tient sur une page partagée. Rien de tout cela n'exige un RSSI, un budget ou un outil spécialisé ; cela exige seulement que quelqu'un soit chargé de la liste.

Les limites de cet article

Disons d'abord ce que cet article ne prétend pas. Il ne s'agit pas d'un audit de sécurité : l'inventaire express ne remplace ni un pentest, ni une revue de code, ni les recommandations complètes de l'ANSSI pour les systèmes d'information. Les chiffres d'exposition cités sont des estimations de sociétés de threat intelligence, publiées en août 2026 : CloudSEK parle d'exposition potentielle, pas de compromission prouvée pour chaque organisation, et Hudson Rock reconnaît qu'une partie des données volées reste inattribuable. La fenêtre d'exposition du 24 mars fait l'objet de comptages divergents, environ 40 minutes selon l'avis officiel, environ trois heures selon Snyk, et nous les rapportons comme telles. Enfin, savoir si votre entreprise figure dans les données exfiltrées relève d'outils spécialisés : Hudson Rock propose un portail de vérification par domaine, et votre prestataire informatique peut rechercher les indicateurs de compromission listés dans l'avis officiel LiteLLM. L'inventaire, lui, reste utile même si vous n'êtes pas dans l'archive : c'est le geste qui rend la prochaine alerte gérable.

Apport Origin : dans nos diagnostics, la sécurité des outils IA n'arrive jamais en premier sujet, elle arrive en premier constat : avant de sécuriser quoi que ce soit, il faut cartographier ce qui existe, et cette cartographie d'une page, outils, clés, accès, propriétaires, est exactement le livrable que nous produisons avec le dirigeant lors d'un premier échange. C'est le même geste que pour la conformité ou les coûts : on ne règle bien que ce qu'on a d'abord inventorié. Le déroulé d'un diagnostic Origin Labs pour une PME de services suit cette logique, et il s'achève sur la liste nommée que cet article vous propose de commencer seul : si la page existe déjà quand nous arrivons, le diagnostic gagne un temps précieux, et il peut porter sur les usages plutôt que sur l'inventaire.

Questions fréquentes

Mon entreprise n'utilise pas LiteLLM, suis-je concerné ?

Possiblement oui, sans le savoir. LiteLLM entre dans les projets comme dépendance transitive d'outils plus visibles : frameworks d'agents, serveurs MCP, connecteurs no-code, prototypes internes. L'avis officiel LiteLLM liste ces cas explicitement. La seule façon de trancher est l'inventaire décrit plus haut, complété si besoin par une recherche des versions 1.82.7 et 1.82.8 dans vos environnements, y compris les pipelines CI/CD et les builds Docker de mars 2026.

Que faire si je découvre qu'une version piégée a tourné chez nous ?

L'avis officiel LiteLLM donne la séquence : considérer comme compromis tout secret présent sur la machine concernée, révoquer et régénérer clés API, identifiants cloud, mots de passe de bases, clés SSH et jetons Kubernetes ; rechercher le fichier (litellm_init.pth) dans les répertoires (site-packages) ; vérifier le trafic sortant vers les domaines indicateurs de compromission. Si vous n'avez pas les compétences en interne, faites accompagner cette passe par votre prestataire informatique, et documentez chaque action.

La faille de juin 2026 est-elle liée à la brèche de mars ?

Non, ce sont deux affaires distinctes sur le même composant. La brèche de mars était une publication malveillante sur PyPI après compromission des accès de publication du projet ; la CVE-2026-42271 de juin est une vulnérabilité du code de LiteLLM lui-même, une injection de commande via les points d'entrée de test MCP, corrigée en version 1.83.7 et inscrite au catalogue KEV de la CISA. Le point commun est la leçon : un composant central de votre pile IA doit être recensé, suivi et maintenu à jour, comme n'importe quel élément d'infrastructure.

Faut-il interdire les outils IA non validés en attendant l'inventaire ?

Interdire ce qui existe déjà est rarement tenable et pousse les usages dans l'invisible. La règle de validation décrite ici vise l'avenir : aucun branchement nouveau sur des données ou des clés sans validation courte et consignée. Pour l'existant, l'inventaire sert à trier : ce qui est utile et borné reste, ce qui détient des accès excessifs est reconfiguré, ce dont personne ne se souvient est débranché. Le but est de rendre l'usage visible, pas de l'interdire.

Sources

• LiteLLM, Security Update : Suspected Supply Chain Incident, avis officiel mis à jour jusqu'au 30 mars 2026 : versions compromises 1.82.7 et 1.82.8, fenêtre d'environ 40 minutes à partir de 10 h 39 UTC, origine Trivy présentée comme probable, indicateurs de compromission et mesures de remédiation, consulté le 26 août 2026.
• Snyk, How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM, 24 mars 2026 : mécanique de la compromission de Trivy, fenêtre d'environ trois heures, environ 3,4 millions de téléchargements quotidiens de LiteLLM.
• Numerama, Cinq jours pour infiltrer, trois heures pour tout voler : comment des hackers ont piégé des millions de développeurs IA, 25 mars 2026 : reconstitution de la découverte par Callum McMahon à 11 h 48 et des cinq jours de préparation.
• CloudSEK, LiteLLM Supply Chain Attack : 2,500+ Companies Exposed in the Largest AI Supply Chain Breach of 2026, 11 août 2026 : plus de 2 500 organisations et environ 434 000 pipelines CI/CD potentiellement exposés.
• Hudson Rock, Largest AI Supply Chain Breach of 2026 : LiteLLM Hack Impacts Thousands of Global Enterprises, 12 août 2026 : archive brute de 153 Go, 433 909 fichiers, 118 829 vidages de runners CI attribués à 2 488 domaines d'entreprise, portail de vérification.
• CISA, Known Exploited Vulnerabilities Catalog, CVE-2026-42271, ajout du 8 juin 2026 : vulnérabilité LiteLLM exploitée et action de remédiation demandée.
• NIST NVD, CVE-2026-42271, détail des deux points d'entrée MCP concernés, versions 1.74.2 à antérieures à 1.83.7 et correctif 1.83.7.
• Akamai, The Telnyx SDK on PyPI Compromise and the 2026 TeamPCP Supply Chain Attacks, 27 mars 2026 : contexte de la campagne TeamPCP et compromission initiale de Trivy le 19 mars 2026.