C'est le stockage centralisé des identifiants qui rend cette vulnérabilité particulièrement à fort impact. Une instance LiteLLM compromise n'expose pas seulement une clé API -- elle expose potentiellement tous les identifiants cloud que l'organisation a configurés sur l'ensemble des fournisseurs de LLM.

Détails de la vulnérabilité

Cause racine

La faille réside dans le processus de vérification des clés API du proxy LiteLLM. Lorsqu'une requête arrive, le proxy vérifie la valeur de l'en-tête Authorization: Bearer dans sa base de données pour authentifier l'appelant. Dans les versions concernées, la valeur du jeton porteur était concaténée directement dans la chaîne de requête SQL au lieu d'être transmise comme entrée paramétrée :

Un guillemet simple dans la valeur du jeton permet à un attaquant d'échapper au littéral de chaîne et d'ajouter des instructions SQL arbitraires. Comme le point d'injection se trouve dans le contrôle d'authentification lui-même, aucun identifiant valide n'est nécessaire pour le déclencher.

Chemin d'attaque

1. L'attaquant envoie une requête HTTP conçue à n'importe quel point de terminaison d'API LLM (par exemple, POST /chat/completions)
2. L'en-tête Authorization: Bearer contient une charge utile d'injection SQL
3. La requête transite par le chemin de gestion des erreurs du proxy et atteint la requête vulnérable
4. L'attaquant peut exécuter des instructions SELECT arbitraires ou potentiellement INSERT/UPDATE/DELETE contre le backend PostgreSQL
5. Les tables de la base de données contenant les clés API, les identifiants des fournisseurs et les données de configuration sont exposées

Ce que les attaquants ont ciblé

L'équipe de recherche sur les menaces de Sysdig a observé des tentatives d'exploitation réelles ciblant :

• La table LiteLLM_VerificationToken -- clés API virtuelles et contrôles d'accès
• Les tables de stockage des identifiants -- clés API des fournisseurs de LLM en amont (OpenAI, Anthropic, etc.)
• Les tables de configuration -- définitions de modèles, budgets de dépenses, paramètres de limites de débit

Chronologie de l'exploitation

La fenêtre d'exploitation de 36 heures est cohérente avec un acteur de menace organisé utilisant des analyses automatisées pour surveiller les nouvelles publications de CVE et développer ou adapter rapidement un code d'exploitation. L'injection SQL est une classe de vulnérabilité bien comprise -- une fois le chemin de code concerné identifié, l'armement est simple.

Évaluation de l'impact

Confidentialité : Élevée -- le contenu de la base de données est lisible, y compris les identifiants
Intégrité : Élevée -- la base de données est inscriptible, les clés peuvent être ajoutées, modifiées ou supprimées
Disponibilité : Moyenne -- le proxy peut être perturbé par une modification de la base de données
Authentification requise : Aucune -- entièrement sans authentification
Accès réseau requis : Oui -- l'attaquant doit pouvoir atteindre le port du proxy

Pourquoi cela va au-delà d'une injection SQL typique : LiteLLM est spécifiquement conçu pour centraliser la gestion des identifiants. Une organisation exécutant une instance LiteLLM compromise peut l'avoir configurée avec des clés API pour OpenAI, Anthropic, Azure OpenAI, AWS Bedrock et d'autres fournisseurs. Chacune de ces clés représente un accès à des services LLM payants avec des limites de dépenses potentiellement importantes. Au-delà de l'abus de dépenses LLM, les identifiants des fournisseurs cloud dans la base de données pourraient permettre un mouvement latéral dans les environnements AWS, Azure ou GCP.

Versions concernées

Opportunités de détection

Niveau réseau/WAF

Recherchez les requêtes HTTP vers les points de terminaison LiteLLM contenant des métacaractères SQL dans l'en-tête Authorization :

Indicateurs à rechercher dans les journaux du proxy :

• Requêtes vers /chat/completions, /embeddings ou d'autres routes API avec des jetons porteurs malformés
• Valeurs de jeton porteur contenant des guillemets simples, des doubles tirets, UNION, SELECT ou d'autres mots-clés SQL
• Volume élevé de réponses 4xx du proxy avec des en-têtes Authorization variés provenant de la même adresse IP source

Niveau base de données

• Requêtes SELECT inattendues contre LiteLLM_VerificationToken avec des clauses WHERE inhabituelles
• Accès aux tables d'identifiants ou de configuration en dehors des modèles de requêtes d'application normaux
• Enregistrements de clés API nouveaux ou modifiés non créés via l'interface d'administration

MITRE ATT&CK

Actions recommandées

Immédiat (si vous exécutez des versions concernées) :

1. Mettez à niveau vers LiteLLM >= 1.83.7-stable immédiatement
2. Si exposé sur Internet pendant la fenêtre de vulnérabilité (19 avril - déploiement du correctif), traitez comme une compromission potentielle -- ne supposez pas que non corrigé = non compromis
3. Faites pivoter toutes les clés API et identifiants cloud stockés dans la base de données LiteLLM
4. Examinez les journaux d'accès du proxy pour détecter des indicateurs d'injection SQL dans les en-têtes Authorization

À court terme : 5. Restreignez l'accès réseau au port du proxy LiteLLM -- il ne doit pas être directement exposé sur Internet sans authentification devant lui 6. Activez la journalisation des requêtes de base de données pour détecter les futures tentatives d'injection 7. Ajoutez des règles WAF pour inspecter les en-têtes Authorization à la recherche de métacaractères SQL

En continu : 8. Abonnez-vous aux alertes KEV de la CISA -- cette vulnérabilité était activement exploitée avant que la plupart des cycles de correctifs ne l'aient détectée 9. Traitez l'infrastructure IA comme des magasins d'identifiants à haute valeur -- les mêmes contrôles de sécurité appliqués aux gestionnaires de secrets devraient s'appliquer aux déploiements de proxy LLM

Notes d'analyse

Pourquoi l'infrastructure IA est une cible croissante : LiteLLM et les outils similaires occupent une position privilégiée -- ils détiennent des identifiants vers des services cloud payants avec des limites de dépenses élevées et sont souvent déployés par les équipes d'ingénierie plutôt que par les équipes de sécurité, avec une revue de sécurité moins mature. L'équipe Sysdig a spécifiquement noté que les opérateurs de LiteLLM « lui font confiance pour centraliser des identifiants de niveau cloud », ce qui en fait une cible attrayante pour le vol d'identifiants et l'abus de services LLM (utilisation de clés API volées pour exécuter leurs propres requêtes contre des modèles payants).

La fenêtre d'exploitation de 36 heures est une référence : Ce n'est pas une anomalie. Les acteurs de menace surveillent activement les flux de publication de CVE et les bases de données d'avis. Pour les vulnérabilités critiques sans authentification dans les logiciels open source largement utilisés, supposez que l'exploitation commence dans les 24 à 48 heures suivant la divulgation publique. Les SLA de correctifs doivent tenir compte de cette réalité -- une fenêtre de correctif de 30 jours n'est pas appropriée pour les vulnérabilités sans authentification avec un score CVSS de 9+.

Le KEV de la CISA comme signal de priorisation : Le catalogue KEV ne comprend que des vulnérabilités avec une exploitation réelle confirmée. Si une CVE apparaît dans le KEV, elle n'est pas théorique -- quelqu'un l'a déjà utilisée contre des cibles réelles. Les organisations doivent traiter les ajouts au KEV comme des actions immédiates, indépendamment de leurs seuils internes de priorisation basés sur le CVSS.

Références

• CISA KEV -- CVE-2026-42208
• Analyse Sysdig TRT
• Couverture The Hacker News
• Security Affairs
• GHSA-r75f-5x8p-qvmc
• MITRE ATT&CK T1190
• MITRE ATT&CK T1555