CVE-2026-42208 : LiteLLM, le proxy IA piraté par SQLi

Ce qui s'est passé

Le 8 mai 2026, l'agence américaine CISA a ajouté la CVE-2026-42208 à son catalogue Known Exploited Vulnerabilities (KEV), marquant officiellement la faille comme exploitée dans la nature. La vulnérabilité affecte LiteLLM, un proxy open source édité par BerriAI qui s'est imposé comme l'une des briques d'orchestration les plus populaires pour les déploiements IA en entreprise. Le composant centralise les appels vers les principaux fournisseurs de modèles (OpenAI, Anthropic, Cohere, Azure OpenAI, Bedrock, Vertex AI) en gérant l'équilibrage de charge, le failover, la limitation de débit, le suivi des coûts et la gestion des clés API.

La faille, notée 9.8 sur l'échelle CVSS, est une injection SQL classique située dans un endpoint de gestion exposé par défaut sur les déploiements non protégés par une authentification réseau forte. Un attaquant non authentifié peut, en envoyant une requête HTTP spécialement conçue, extraire le contenu de la base interne du proxy. Cette base contient typiquement les clés API des fournisseurs LLM utilisés, les jetons d'authentification des utilisateurs internes, les paramètres de connexion à PostgreSQL ou Redis, et l'historique des requêtes proxifiées si le mode trace est activé.

BerriAI a publié le correctif dans la version 1.48.3 le 2 mai 2026, après divulgation responsable par un chercheur dont l'identité n'a pas été rendue publique. La distance de six jours seulement entre la publication du patch et l'ajout au KEV de CISA témoigne d'une exploitation extrêmement rapide : selon plusieurs équipes de réponse à incident, des analystes ont commencé à observer des scans de masse ciblant les endpoints LiteLLM dès le 4 mai, soit moins de 48 heures après la publication du correctif. Plusieurs cas d'exfiltration de clés API ayant ensuite servi à siphonner du quota de modèles de pointe (notamment Claude Opus et GPT-5.5) ont été documentés.

Les conséquences d'une exfiltration de clés API LLM dépassent largement le simple vol de quota. Beaucoup d'entreprises stockent dans LiteLLM des clés associées à des comptes Bedrock ou Vertex AI ayant accès à des projets cloud entiers, parfois bien au-delà du périmètre IA. La fuite d'une clé API mal scopée peut donc se transformer en pivot vers du stockage objet, des bases de données ou des services internes hébergés sur le même tenant cloud. Plusieurs incidents en cours d'investigation porteraient justement sur ce type de pivot.

L'agenda de mitigation de CISA fixe au 29 mai 2026 la date limite à laquelle les agences fédérales américaines doivent avoir patché ou retiré leurs instances LiteLLM exposées, sous peine de manquements documentés. Les opérateurs privés ne sont pas soumis à cette deadline mais sont invités à s'aligner. Les éditeurs cloud de leur côté, notamment AWS et Azure, ont commencé à pousser des notifications aux clients exécutant des images publiques contenant LiteLLM, signalant le besoin urgent de mise à jour.

Sur le plan technique, plusieurs vendeurs de threat intelligence ont publié des règles de détection : signatures Suricata sur les motifs d'injection observés dans les logs Nginx en amont de LiteLLM, requêtes Splunk pour repérer les requêtes anormales sur les endpoints concernés, et règles Sigma génériques pour les déploiements en self-hosted. Pour les équipes ayant déployé LiteLLM derrière une passerelle d'API ou un WAF moderne, l'ajout d'une règle de blocage sur les motifs SQL classiques offre une mesure compensatoire en attendant le patch.

Cet incident s'ajoute à une série préoccupante touchant les infrastructures IA d'entreprise. Au cours du seul mois de mai 2026, le bac à sable Node.js vm2 a vu douze CVE critiques publiées simultanément, l'attaque sur le SaaS Braintrust a entraîné une rotation forcée des clés API clients, et plusieurs implémentations RAG construites sur des bases vectorielles open source se sont retrouvées exposées sans authentification. Le pattern est récurrent : des composants open source jeunes, déployés rapidement pour répondre à la vague IA, dont la maturité sécurité ne suit pas le rythme de l'adoption.

Pour les RSSI, la question dépasse le seul patch LiteLLM. Elle pose celle de la cartographie des composants IA déployés dans l'entreprise, souvent en dehors des canaux d'approvisionnement classiques de la DSI. Les équipes data science et applicatives sont souvent celles qui ont déployé LiteLLM, parfois en quelques heures, sur un Kubernetes accessible depuis l'extérieur ou sur une VM avec une authentification minimaliste. La criticité réelle de ces déploiements n'apparaît dans aucun CMDB et leur durée de vie échappe au suivi traditionnel.

Pourquoi c'est important

LiteLLM symbolise une nouvelle catégorie de composants critiques apparue avec la vague IA générative : les passerelles LLM. Ces proxies se sont imposés comme un point d'entrée unique pour rationaliser les coûts, gouverner les usages et appliquer des règles internes (filtrage de prompts, rétention, audit). Mais cette centralisation crée un point de concentration de secrets dont la compromission peut tout faire basculer. Une seule injection SQL réussie expose en pratique l'intégralité du bus IA d'une entreprise.

L'incident illustre aussi la maturation du marché des attaquants ciblant l'écosystème IA. Si les premiers cas d'abus se limitaient à du vol de quota revendu sur des marchés gris (les fameux « DarkBard » et autres pages de revente), on observe désormais une professionnalisation : exploitation rapide après publication des correctifs, ciblage privilégié des proxies pour atteindre des secrets en cascade, valorisation des clés API LLM auprès de groupes plus matures. Le délai moyen entre publication d'un correctif IA critique et observation d'attaques de masse est passé sous les 72 heures.

Pour les organisations soumises à NIS2, l'entrée en scène des composants IA dans le périmètre des « éléments essentiels » impose une revue de la cartographie des actifs. La chaîne d'approvisionnement logicielle inclut désormais des dépendances comme LiteLLM, Langchain, Ollama ou des bases vectorielles, dont la criticité est souvent sous-estimée. Documenter ces composants, leur version, leur exposition et leur cycle de patch devient un sujet de conformité, et plus seulement de bonne pratique.

Enfin, l'affaire LiteLLM relance une question stratégique pour les directions générales : faut-il continuer à laisser les équipes data déployer librement des composants open source IA ou faut-il introduire un process de validation sécurité à l'image de ce qui existe pour les bibliothèques applicatives traditionnelles. La rapidité d'innovation reste un argument fort, mais la concentration des risques dans des composants jeunes plaide pour un encadrement plus formel, sans pour autant tuer la dynamique d'expérimentation.

Ce qu'il faut retenir

• Mettre à jour LiteLLM vers la version 1.48.3 ou supérieure de toute urgence sur l'ensemble des déploiements internes et publics.
• Considérer comme compromises toutes les clés API stockées dans une instance LiteLLM exposée à Internet avant le patch et procéder à leur rotation systématique.
• Cartographier l'ensemble des composants IA open source déployés dans l'organisation (proxies LLM, frameworks RAG, bases vectorielles) pour les intégrer au cycle de gestion des vulnérabilités au même titre que les bibliothèques applicatives.