Faille LiteLLM : 2 500 entreprises exposées par une attaque supply chain — pourquoi votre PME doit auditer sa chaîne d'outils IA maintenant

Le 11 août 2026, la société de cybersécurité CloudSEK a publié un rapport qui devrait alerter tout dirigeant de PME utilisant l'intelligence artificielle. Une attaque par chaîne d'approvisionnement — dite « supply chain » — a compromis LiteLLM, un composant logiciel open source utilisé par plus de 2 500 entreprises dans le monde pour connecter leurs applications à différents modèles d'IA (Claude, GPT, Gemini, Mistral). Pendant 20 jours, une version piégée de ce composant a silencieusement aspiré des clés API, des identifiants cloud, des secrets Kubernetes et des tokens d'accès à des dépôts de code. Parmi les organisations touchées : NVIDIA, AWS, Cisco, Salesforce, Siemens, Orange. Mais le plus inquiétant n'est pas la liste des géants exposés — c'est que des milliers de PME utilisent les mêmes composants sans même le savoir. LiteLLM est une brique invisible : elle est intégrée dans les plateformes d'automatisation, les agents IA personnalisés et les outils no-code que les PME déploient chaque jour. Si votre entreprise utilise l'IA en production, vos clés API circulent dans une chaîne de dépendances que vous n'avez probablement jamais auditée. Voici ce qui s'est passé, pourquoi c'est un signal d'alarme pour les PME françaises, et les 5 actions concrètes à mettre en place immédiatement.

LiteLLM : le composant invisible qui connecte vos outils IA entre eux

LiteLLM est un proxy open source qui permet d'appeler différents modèles d'IA — Claude d'Anthropic, GPT d'OpenAI, Gemini de Google, Mistral — via une interface unifiée. Au lieu de coder une connexion spécifique pour chaque fournisseur d'IA, les développeurs utilisent LiteLLM comme couche d'abstraction : une seule intégration, tous les modèles accessibles. C'est un gain de temps considérable, et c'est pour cette raison que le composant est devenu omniprésent. Le problème, c'est que cette omniprésence en fait une cible de choix. LiteLLM est installé comme une dépendance Python — un package téléchargé depuis le registre PyPI — et il est souvent intégré dans d'autres outils sans que l'utilisateur final ne le sache. Si votre PME utilise un agent IA développé par un prestataire, un outil d'automatisation connecté à plusieurs modèles, ou un chatbot personnalisé qui switche entre Claude et GPT selon la tâche, il y a de fortes chances que LiteLLM — ou un composant similaire — soit quelque part dans la chaîne. Vos clés API (les « mots de passe » qui donnent accès à vos comptes IA payants) transitent par ces composants intermédiaires. Et c'est exactement ce que les attaquants ont exploité.

Anatomie de l'attaque : comment un scanner de sécurité est devenu la porte d'entrée

L'attaque, orchestrée par un groupe identifié sous le nom de Team PCP, est un cas d'école de compromission supply chain. En mars 2026, les attaquants ont d'abord compromis Trivy, un scanner de sécurité utilisé dans le pipeline de construction de LiteLLM. L'ironie est cruelle : c'est l'outil censé détecter les failles qui a servi de porte d'entrée. Via ce scanner compromis, les attaquants ont obtenu les tokens de publication PyPI de LiteLLM — les clés qui permettent de publier de nouvelles versions du package. Ils ont ensuite publié deux versions piégées (1.82.7 et 1.82.8) sur PyPI, le registre officiel de packages Python. Ces versions contenaient un fichier .pth qui s'exécute automatiquement au démarrage de Python, sans même que le code soit explicitement importé. Résultat : toute machine ayant installé ces versions pendant les 40 minutes où elles étaient en ligne a vu ses variables d'environnement — clés API, secrets cloud, identifiants de base de données — silencieusement exfiltrées vers les serveurs des attaquants. Quarante minutes peuvent sembler courtes, mais dans l'écosystème Python où les mises à jour automatiques sont la norme, c'est amplement suffisant pour toucher des milliers de systèmes.

Pourquoi les PME sont en première ligne — même sans utiliser LiteLLM directement

La plupart des dirigeants de PME vont lire cette actualité et penser : « nous n'utilisons pas LiteLLM, ça ne nous concerne pas ». C'est précisément le problème des attaques supply chain : la victime finale n'a souvent aucune relation directe avec le composant compromis. Votre PME n'a pas besoin d'avoir installé LiteLLM pour être exposée. Il suffit qu'un outil que vous utilisez l'ait fait. Trois scénarios concrets illustrent ce risque pour une PME française. Premier scénario : votre prestataire technique a développé un agent IA personnalisé pour automatiser votre service client. Il utilise LiteLLM en interne pour router les requêtes vers Claude ou GPT selon la complexité. Vos clés API sont configurées dans l'environnement de cet agent. Deuxième scénario : vous utilisez un outil SaaS qui intègre LiteLLM dans son backend pour proposer du « multi-modèle » à ses clients. Vos données transitent par un composant que vous n'avez jamais audité. Troisième scénario : un développeur freelance a utilisé LiteLLM dans un script d'automatisation qu'il a déployé sur votre serveur il y a six mois. Personne ne sait exactement quelles dépendances ce script utilise, ni si elles ont été mises à jour. Dans les trois cas, la PME est exposée sans avoir pris aucune décision technique consciente. C'est la nature même du risque supply chain : il se propage à travers les couches de la pile logicielle, invisiblement.

La bombe à retardement des identifiants volés : pourquoi agir maintenant

L'aspect le plus urgent de cette faille n'est pas la compromission initiale de mars 2026 — c'est ce qui se passe avec les identifiants volés depuis. Le FBI a émis un avis FLASH le 2 juillet 2026 avertissant que les identifiants exfiltrés restent exploitables tant qu'ils ne sont pas révoqués par leur propriétaire. Autrement dit : même si les versions piégées de LiteLLM ont été retirées depuis cinq mois, les clés API volées pendant la fenêtre d'exposition sont toujours valides. Un attaquant qui possède votre clé API OpenAI ou Anthropic peut générer des milliers d'euros de consommation à votre charge. Avec vos identifiants cloud AWS ou Google Cloud, il peut accéder à vos données, déployer des machines de minage de cryptomonnaie, ou utiliser votre infrastructure comme relais pour d'autres attaques. Avec vos tokens GitHub, il peut modifier votre code source, injecter des portes dérobées ou accéder à des données sensibles stockées dans vos dépôts privés. Le coût moyen d'une compromission de clés API pour une PME est estimé entre 5 000 et 50 000 € selon le périmètre touché — sans compter les conséquences réputationnelles et le temps de remédiation.

5 actions concrètes pour auditer et sécuriser votre stack IA

• Inventoriez vos clés API et identifiants IA : listez chaque clé API (OpenAI, Anthropic, Google, Mistral) utilisée dans vos outils, agents et automatisations. Identifiez où elles sont stockées — variables d'environnement, fichiers de configuration, plateformes d'automatisation (Make, n8n, Zapier). Si vous ne savez pas combien de clés actives vous avez, c'est le premier signal d'alarme.
• Effectuez une rotation immédiate de toutes vos clés API IA : connectez-vous à chaque console fournisseur (console.anthropic.com, platform.openai.com, console.cloud.google.com) et régénérez vos clés. Mettez à jour les nouvelles clés dans tous vos outils. La rotation prend 15 minutes par fournisseur — c'est la mesure la plus efficace et la moins coûteuse.
• Auditez les dépendances de vos outils IA : demandez à votre prestataire technique la liste des packages et composants utilisés dans vos solutions IA. Vérifiez si LiteLLM, ou tout proxy multi-modèles, fait partie de la chaîne. Si c'est le cas, assurez-vous que la version en production est postérieure à la correction (1.82.9+) et que les identifiants ont été renouvelés.
• Activez les alertes de consommation sur chaque compte IA : configurez des seuils d'alerte sur vos comptes fournisseurs IA. Si une clé volée est utilisée, une consommation anormale sera le premier signal visible. Sur Anthropic, OpenAI et Google Cloud, les alertes de facturation se configurent en moins de 5 minutes.
• Mettez en place une politique de gestion des secrets : ne stockez plus jamais de clés API en clair dans des fichiers de configuration ou des variables d'environnement non protégées. Utilisez un gestionnaire de secrets (même gratuit, comme les secrets GitHub Actions ou les variables d'environnement chiffrées de votre hébergeur). Limitez la durée de vie de vos clés et planifiez une rotation trimestrielle.

Comment Lesage.AI sécurise votre infrastructure IA

• Audit de sécurité de votre stack IA (2-3 heures) : nous cartographions l'ensemble de vos outils IA — agents, automatisations, chatbots, scripts — et identifions chaque composant tiers dans la chaîne de dépendances. Vous obtenez une vue complète de votre surface d'exposition, avec les clés API à renouveler en priorité et les composants à mettre à jour.
• Rotation et sécurisation des identifiants : nous effectuons la rotation de toutes vos clés API IA, configurons les alertes de consommation anormale sur chaque fournisseur, et mettons en place un gestionnaire de secrets adapté à votre infrastructure — du simple coffre-fort chiffré aux solutions professionnelles selon vos besoins.
• Architecture IA sécurisée dès la conception : pour vos nouveaux projets d'automatisation IA, nous concevons des architectures qui isolent les secrets, limitent les permissions au strict nécessaire, et intègrent des contrôles de sécurité à chaque étape — sans ralentir vos workflows ni complexifier votre stack.
• Veille et alerte continue : nous surveillons les bulletins de sécurité des composants IA que vous utilisez et vous alertons dès qu'une faille est identifiée dans votre chaîne de dépendances — avant qu'elle ne soit exploitée.