LiteLLM CVE-2026-42208 : une injection SQL pré-authentifiée dans la passerelle IA

Qu’est-ce que CVE-2026-42208 ?

CVE-2026-42208 (GHSA-r75f-5x8p-qvmc, CVSS 9.3) est une injection SQL pré-authentifiée dans LiteLLM, le proxy open source compatible OpenAI cumulant plus de 22 000 étoiles GitHub et qui fronte OpenAI, Anthropic, Bedrock et des dizaines d’autres fournisseurs de modèles. L’avis côté mainteneur a été publié le 20 avril 2026, le correctif est arrivé dans v1.83.7 le 19 avril, et l’entrée a été répliquée dans la GitHub Advisory Database globale le 24 avril 2026. L’équipe Sysdig Threat Research a observé la première tentative d’exploitation ciblée 36 heures et sept minutes plus tard, le 26 avril à 04h24 UTC. La CISA a ajouté le CVE à son catalogue Known Exploited Vulnerabilities le 8 mai 2026.

Comment ça fonctionne

Dans les versions affectées (v1.81.16 à v1.83.6), le chemin de vérification de clé API du proxy concatène la valeur de l’en-tête Authorization: Bearer directement dans un SELECT sur la table LiteLLM_VerificationToken, sans liaison de paramètres. Le contrôle s’exécute avant la décision d’authentification : tout ce qui peut atteindre le port du proxy peut donc piloter du SQL arbitraire.

La forme observée par Sysdig est directe :

POST /chat/completions HTTP/1.1
Authorization: Bearer sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL FROM "LiteLLM_VerificationToken"--
User-Agent: Python/3.12 aiohttp/3.9.1

Le préfixe sk-litellm' n’est pas une vraie clé — le guillemet simple final ferme le littéral SQL pour que le UNION s’exécute sur la colonne exfiltrée. Deux détails de l’attaquant comptent pour les défenseurs. D’abord, il connaissait déjà l’identifiant PascalCase généré par Prisma ("LiteLLM_VerificationToken"), ce qui suppose la lecture préalable du schéma open source de LiteLLM. Ensuite, les toutes premières salves visaient les trois tables à plus forte valeur du proxy : LiteLLM_VerificationToken (clés virtuelles et master key), litellm_credentials.credential_values (credentials bruts des fournisseurs amont) et litellm_config.config_value WHERE param_name='environment_variables' (l’environnement d’exécution du proxy, qui inclut typiquement le DSN PostgreSQL et les URL de webhook).

Le correctif tient en une ligne : remplacer l’interpolation de chaîne par une requête paramétrée. Il est apparu dans v1.83.7 et les mainteneurs recommandent désormais v1.83.10-stable.

Pourquoi c’est important

Une injection SQL contre une application web générique fuite des lignes. Une injection SQL contre une passerelle IA fuite les clés de tous les comptes de modèles qu’elle intermédie. Une seule ligne litellm_credentials contient régulièrement une clé d’organisation OpenAI de production avec un plafond mensuel à cinq chiffres, une clé console Anthropic avec droits workspace-admin, et un identifiant IAM AWS Bedrock. Une fois volées, ces clés peuvent être rejouées contre /chat/completions depuis n’importe quelle IP — LiteLLM ne lie pas les clés à une source par défaut. Le rayon d’explosion s’apparente à une compromission de compte cloud plus qu’à un SQLi web classique.

Trois motifs plus larges méritent l’attention, cohérents avec LMDeploy SSRF (CVE-2026-33626) et la vague plus large de CVE infrastructure IA de 2026 :

• Les passerelles IA sont des surfaces de credentials de premier rang. Elles agrègent des secrets fournisseur qui se trouvaient jusqu’ici derrière des frontières distinctes.
• Les fenêtres d’exploitation se réduisent. 36 heures entre l’avis et une exploitation au fait du schéma, sans PoC public. Les pipelines défenseurs branchés sur CISA KEV n’auraient pas remonté l’alerte à temps.
• La connaissance du schéma précède le payload. Les ORM open source publient les noms de tables dont les attaquants ont besoin. Le coût de la reconnaissance tend vers zéro.

Défenses

Étapes concrètes, par ordre d’urgence :

• Mettez à jour immédiatement vers v1.83.10-stable (ou toute version >= v1.83.7). Si le patch est bloqué, placez le proxy derrière un reverse-proxy qui rejette tout en-tête Authorization contenant un guillemet simple, des parenthèses, ou les jetons UNION, SELECT, FROM, --.
• Traitez la base comme compromise pour toute instance accessible depuis Internet qui a tourné sur une version vulnérable. Faites tourner toutes les clés virtuelles, la master key et chaque credential fournisseur stocké. Auditez les portails de facturation amont à la recherche de trafic /chat/completions provenant d’IPs sources inconnues.
• Sortez le proxy d’Internet. Les passerelles IA consolident assez de valeur en credentials pour qu’une exposition publique ne soit plus défendable par défaut — placez-les derrière du mTLS ou un proxy d’identité d’entreprise.
• Liez les clés à une source. Quand la plateforme le permet, restreignez les clés virtuelles aux IP clientes ou aux identités de service attendues : une clé exfiltrée ne sera plus interchangeable avec l’appelant légitime.
• Surveillez la signature de requête. Une unique requête Authorization: Bearer sk-litellm' est un indicateur à forte confiance. Les IOC de Sysdig couvrent les deux IP sources 65.111.27.132 et 65.111.25.67 (AS200373).
• Inventoriez la surface passerelle. Les équipes applicatives installent régulièrement LiteLLM, OpenLLM et outils similaires hors du circuit sécurité standard. Trouvez-les avant un tiers.

État

Élément	Date	Statut
Correctif publié (v1.83.7)	19 avr. 2026	Public
Avis mainteneur (GHSA)	20 avr. 2026	Public
Indexation GHSA globale	24 avr. 2026	Public
Première tentative d’exploitation observée	26 avr. 2026	Public (Sysdig)
Article de blog LiteLLM	29 avr. 2026	Public
Ajout au catalogue CISA KEV	8 mai 2026	Public
Version recommandée	v1.83.10-stable	Actuelle

La conclusion est inconfortable mais actionnable : en mai 2026, une passerelle LLM exposée à Internet sur une version vulnérable doit être considérée comme compromise, et non simplement vulnérable.