CVE-2026-42208 : SQL injection LiteLLM proxy IA au KEV

Les faits

La CISA a ajouté le 8 mai 2026 la vulnérabilité CVE-2026-42208 à son catalogue Known Exploited Vulnerabilities (KEV), confirmant officiellement l''exploitation active d''une faille critique d''injection SQL dans LiteLLM. Le projet open-source, qui agrège plus de 22 000 étoiles sur GitHub, sert de gateway unifié pour appeler indifféremment les API d''OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, Google Vertex et plus de cent autres fournisseurs LLM. Sa popularité auprès des équipes data, IA et plateformes en fait une cible de choix : un seul proxy compromis livre généralement la totalité des clés des fournisseurs en aval.

La faille porte un score CVSS de 9.3 et a été initialement divulguée par Bishop Fox, qui l''a découverte lors d''un audit du proxy. Elle se loge dans la requête SQL utilisée pour vérifier la validité d''une clé API virtuelle lorsqu''un client envoie un appel vers les routes /chat/completions, /embeddings ou toute autre route LLM standard. Au lieu de passer la valeur de l''en-tête Authorization en paramètre lié, le code la concatène directement dans le texte de la requête SELECT contre la table LiteLLM_VerificationToken. Une simple apostrophe permet à l''attaquant de sortir du littéral SQL et d''ajouter sa propre clause UNION ou sous-requête.

L''exploitation se fait sans aucune authentification : il suffit d''envoyer une requête HTTP POST vers une route LLM standard avec un en-tête Authorization de la forme « Bearer sk-litellm''-- ». Le préfixe sk-litellm'' n''a pas besoin d''être une vraie clé. La requête traverse le chemin de gestion d''erreurs du proxy, qui exécute néanmoins la requête de vérification injectée. L''attaquant récupère ainsi des données via des messages d''erreur ou des canaux secondaires, ou peut écrire dans la base si l''utilisateur PostgreSQL/MySQL du proxy a les droits d''écriture, ce qui est le cas par défaut.

La chronologie de l''exploitation illustre la rapidité du cycle moderne entre divulgation et abus. La version corrigée 1.83.7-stable a été publiée le 19 avril 2026. Le bulletin de sécurité a été indexé dans la GitHub Advisory Database peu après. Selon Sysdig, la première tentative d''exploitation a été observée le 26 avril 2026 à 16h17 UTC, soit environ 26 heures après l''indexation publique de l''avis. The Hacker News rapporte que d''autres rapports placent ce délai à 36 heures, ce qui reste un fenêtre extrêmement courte pour qu''un opérateur déploie un correctif dans son cluster Kubernetes ou son orchestration Docker.

Techniquement, la racine du problème est un anti-pattern classique : la clé Bearer est interpolée dans une chaîne SQL au lieu d''être passée comme paramètre. Dans toutes les versions vulnérables, le contrôleur d''authentification du proxy lit l''en-tête Authorization, retire le préfixe « Bearer », puis construit la requête de vérification par concaténation de chaînes. Aucune fonction d''échappement n''est appelée, et aucune préparation de requête côté ORM n''est utilisée. Toute valeur passée par le client se retrouve donc évaluée comme du SQL si elle contient une apostrophe.

L''acteur observé par Sysdig et Bishop Fox a immédiatement ciblé deux tables précises : litellm_credentials, en particulier la colonne credential_values, et litellm_config. La première contient les identifiants utilisés par le proxy pour appeler les fournisseurs LLM en aval — typiquement une clé OpenAI au format sk-..., une clé Anthropic au format sk-ant-..., et un couple AWS Access Key/Secret Key pour Bedrock. La seconde contient des paramètres de configuration globale, dont les chaînes de connexion et certaines variables d''environnement sensibles. La cinétique de l''attaque montre une connaissance précise du schéma interne, ce qui suggère que les opérateurs avaient préparé leurs requêtes en lisant le code source open-source dès la publication du commit correctif.

L''impact réel d''une compromission dépasse largement celui d''une SQLi classique. Une seule ligne de la table litellm_credentials peut contenir simultanément une clé OpenAI d''organisation avec un plafond mensuel à cinq chiffres, une clé console Anthropic avec droits d''administration de workspace, et une paire IAM AWS donnant accès à Bedrock dans plusieurs régions. La compromission d''un proxy LiteLLM exposé sur Internet équivaut donc moins à une fuite applicative qu''à un take-over multi-cloud, avec capacité de générer des coûts importants en quelques minutes via des appels massifs aux modèles les plus chers, ou de pivoter vers d''autres ressources si les clés AWS ont des permissions trop larges.

Aucun PoC public exhaustif n''est encore publié à la date de cette alerte, mais la forme canonique observée par Sysdig est suffisamment simple pour qu''un opérateur compétent reconstruise l''attaque en quelques heures. Plusieurs honeypots ont déjà capturé des variantes utilisant des UNION SELECT pour extraire les colonnes de credential_values en base64. La présence sur le KEV implique une obligation pour les agences fédérales américaines (BOD 22-01) de patcher dans le délai imparti, mais le signal s''adresse en réalité à toute organisation exploitant LiteLLM, qu''elle soit fédérale ou non.

Impact et exposition

Toute instance LiteLLM exposée sur Internet en versions 1.81.16 à 1.83.6 est exploitable sans authentification préalable. Les déploiements en SaaS interne — derrière un reverse-proxy authentifié, un VPN ou une mTLS — réduisent la surface mais ne suppriment pas le risque, car la faille peut être déclenchée par tout utilisateur ayant simplement accès au point de terminaison HTTP, même non authentifié au niveau LiteLLM. Les images Docker officielles, les Helm charts communautaires et les packages PyPI installés en proxy vers des fournisseurs LLM tiers sont concernés.

L''exploitation active est confirmée par Sysdig, Bishop Fox et la CISA. Au moins un acteur opportuniste cible les instances exposées via Shodan et FOFA, en testant la présence de routes /chat/completions ouvertes. Les tentatives observées ne se contentent pas de la lecture : certaines extractions sont suivies d''appels massifs vers les API tierces avec les clés volées, ce qui matérialise la perte financière dès la première heure suivant la compromission.

La surface d''attaque est large pour deux raisons. D''abord, LiteLLM est devenu un composant standard dans les architectures GenAI d''entreprise depuis 2024, avec des dizaines de milliers de déploiements estimés. Ensuite, beaucoup d''opérateurs exposent volontairement le proxy au public ou à des sous-réseaux étendus pour permettre à des outils internes hétérogènes (notebooks Jupyter, applications mobiles, agents conversationnels) de l''appeler. La conjonction « proxy public + clés LLM payantes en base » constitue une cible idéale pour des acteurs motivés financièrement.

Recommandations immédiates

• Mettre à jour LiteLLM vers la version 1.83.7-stable ou supérieure. La correction passe par l''utilisation de paramètres liés dans la fonction de vérification de clé.
• Faire une rotation complète de toutes les clés API virtuelles, master keys et identifiants fournisseurs (OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, Vertex, etc.) pour toute instance LiteLLM ayant été accessible sur Internet en version vulnérable, même si aucun signe de compromission n''est visible.
• Auditer les logs HTTP à la recherche de requêtes contenant le motif « Bearer sk-litellm'' », « UNION SELECT » dans l''en-tête Authorization, ou des requêtes inhabituellement longues vers /chat/completions.
• Restreindre l''accès réseau au proxy LiteLLM via un reverse-proxy authentifié, mTLS ou ACL au niveau du load-balancer pour réduire la surface d''attaque future.
• Surveiller la facturation OpenAI, Anthropic et AWS Bedrock pour détecter tout pic anormal dans les heures suivant la mise à jour, indicateur typique d''une exfiltration de clés antérieure au patch.