Qu’est-ce que la sécurité d’une passerelle IA, et pourquoi les failles LiteLLM de 2026 comptent-elles ?

Une passerelle IA réunit sur une seule machine les clés de fournisseurs, les identifiants de tenants et les connexions aux outils que vos produits utilisent pour atteindre un modèle. La sécurité d’une passerelle IA tient donc moins au trafic qu’elle inspecte qu’à ce qu’une intrusion sur cette machine livre : clés, base du proxy, outils connectés, identité cloud. La conception qui limite la casse y stocke le moins possible.

Entre mai et septembre 2026, la CISA a inscrit trois failles LiteLLM à son catalogue des vulnérabilités connues et exploitées (KEV), et le 2026-09-02 une faille de Starlette dont la fiche dit qu’elle s’enchaîne avec l’une d’elles. Le 2026-10-27, Red Hat a publié une faille de passerelle d’un autre genre, dans un composant d’OpenShift AI : une requête qui désigne le modèle d’un autre tenant se voit injecter les clés de ce tenant. Je n’ai ni audité ni fait tourner LiteLLM ; ce qui suit s’en tient aux fiches.

Quand (date au catalogue) Ce qui a cédé Ce qu’il fallait à l’appelant Ce qui était exposé
2026-05-08 Injection SQL dans la vérification des clés API (CVE-2026-42208) Aucune clé : un en-tête Authorization forgé sur n’importe quelle route LLM La base du proxy et les identifiants qu’il gère
2026-06-08 Injection de commandes dans les points d’entrée de test MCP (CVE-2026-42271) N’importe quelle clé de proxy valide, même à faibles privilèges Des commandes arbitraires sur l’hôte, sous l’identité du proxy
2026-09-02 Traitement de l’en-tête Host par Starlette (CVE-2026-48710) Aucune clé : un en-tête Host malformé Ce qu’un contrôle fondé sur le chemin protégeait
2026-09-02 Repli d’authentification MCP (CVE-2026-59822) Aucune clé : n’importe quelle valeur Bearer Une session MCP : outils configurés et services connectés
2026-10-27, Red Hat, hors catalogue Sélection des identifiants par un identifiant de modèle fourni par le client (CVE-2026-117574) L’identifiant d’un tenant L’usage des clés de fournisseur d’un autre tenant, et son quota

Cinq fiches. À chaque fois, ce qui valait la peine d’être pris était déjà dans la passerelle.

Que récupère un attaquant dans une passerelle ?

Les clés de fournisseurs d’abord. La note de la Cloud Security Alliance sur l’injection de commandes énumère ce qu’une commande lancée sous l’identité du proxy peut lire : variables d’environnement portant les clés, fichiers d’identifiants montés, configuration, base. Son conseil de renouveler toutes les clés que le proxy détenait est aussi un aveu.

La base du proxy est le deuxième butin. La fiche du catalogue pour l’injection SQL se termine sur un accès non autorisé au proxy et aux identifiants qu’il gère, et l’avis précise le chemin : un en-tête forgé sur n’importe quelle route LLM atteignait la requête par la gestion d’erreur. La note de la CSA ajoute la configuration d’accès qu’un déploiement détient, qui dit quelles équipes et quels services peuvent accéder à quels modèles.

Vient ensuite une session MCP, et tout ce qu’il y a derrière : l’avis du contournement d’authentification indique qu’un attaquant pouvait lister et appeler les outils MCP configurés et atteindre les services connectés, et Wiz montre un en-tête Authorization: Bearer a qui en ouvre une. Wiz va un cran plus loin, avec une fonction de pass-through qui relaie les requêtes vers n’importe quelle URL configurée par un administrateur, en-têtes compris, sans contrôle sur l’adresse des métadonnées ; pointée sur 169.254.169.254, elle renvoyait les identifiants du rôle de l’hôte, et l’intrusion dans la passerelle devenait une intrusion dans le cloud.

La fiche Red Hat ajoute la version multi-tenant de la même erreur. Un magasin d’identifiants partagé était interrogé avec l’identifiant de modèle envoyé par l’appelant, sans contrôle d’autorisation, si bien que le service a utilisé les clés d’un autre tenant pour la requête de l’appelant. Elle touche un seul composant nommé, ne figure pas au catalogue et n’a pas été signalée comme exploitée.

La passerelle doit-elle détenir des clés de fournisseurs ?

Pas quand le fournisseur permet de s’en passer, et Amazon Bedrock le permet. Dans la conception de passerelle Bedrock que j’ai publiée, la passerelle appelle Bedrock avec un rôle IAM et ne détient aucune clé de fournisseur. Un rôle n’a pas d’identifiants permanents : quand la passerelle l’endosse, STS émet des identifiants temporaires pour la session, qui expirent.

La politique du rôle n’autorise l’invocation que sur les profils d’inférence UE approuvés, par la clé de condition bedrock:InferenceProfileArn, et une politique de contrôle des services (SCP) plafonne ce que le rôle peut faire quoi qu’en dise sa politique : AWS décrit les SCP comme les permissions maximales d’un compte membre, qui n’accordent rien par elles-mêmes. Les deux sont dans le guide de conception de la passerelle sur Bedrock, couche 1 de l’architecture de plateforme IA d’entreprise, avec la même réserve : une conception à tester d’abord sur une unité d’organisation.

Ce que le rôle change, et ce qu’il ne change pas

Que vaut une session volée ? Les appels que la passerelle pouvait faire, sur les mêmes profils UE, pour le reste de la session, chacun dans CloudTrail au nom du rôle, puisque Bedrock enregistre Converse et InvokeModel comme événements de gestion. Cela vaut encore quelque chose, vos modèles sur votre facture, le LLMjacking que décrit Wiz. Darktrace a décrit un cas réel en juillet 2026, sans vol sur Bedrock : une instance EC2 nommée LiteLLM-Proxy, profil d’instance capable d’atteindre Bedrock, SSH ouvert, utilisée pour du minage. Remarquez-le à temps, et AWS permet de retirer toutes les permissions aux sessions émises avant un instant choisi.

Ce que le rôle ne change pas : une session prélevée dans le processus (sur EKS, le fichier de jeton d’identité web que le pod échange contre les identifiants du rôle) ou sur le service de métadonnées fonctionne jusqu’à expiration. Le pass-through reste donc coupé, la sortie réseau et l’accès aux métadonnées sont restreints : IMDSv2 exigé et --http-put-response-hop-limit 1, comme le montre le guide des bonnes pratiques EKS ; la page IRSA d’AWS dit que l’isolation des identifiants entre pods ne tient qu’à cette condition.

Quand le fournisseur ne laisse d’autre choix qu’une clé

Un fournisseur sans identité de charge de travail impose une clé, qui demande plus de soin. Elle se lit dans un gestionnaire de secrets à l’appel, pas dans l’environnement au démarrage, puisque l’injection de commandes lisait l’environnement. Il en faut une par tenant ou par produit, sous le plafond de dépense du fournisseur, renouvelée via Secrets Manager, par une fonction Lambda à défaut de rotation gérée. Pas de magasin partagé interrogé par un nom que l’appelant envoie. Rien de cela ne cache la clé au code du processus : le chiffrement au repos, que WSO2 documente avec AES-GCM et un Secret Kubernetes, protège la copie stockée, et le processus la déchiffre pour s’en servir.

Quelles fonctions de passerelle couperais-je ?

Les fonctions derrière ces failles exécutent quelque chose fourni par l’appelant, ou relaient un identifiant. Une passerelle qui authentifie, route, limite et journalise n’a besoin d’aucune d’elles.

L’avis de la CVE-2026-42271 décrit deux points d’aperçu qui prenaient command, args et env dans le corps de la requête et lançaient la commande sur l’hôte. Je n’en exposerais aucun, rôle administrateur ou non ; le coût, c’est de tester les configurations MCP en CI plutôt que depuis la console.

Les garde-fous en code personnalisé. Wiz décrit un point d’enregistrement qui passait le Python soumis à exec, corrigé depuis ; un garde-fou qui est du code est de l’exécution à distance sous un nom plus aimable. Sur Bedrock, je laisserais le compte appliquer les Guardrails à chaque invocation. Le coût : les garde-fous deviennent de la configuration, ou un service à part avec sa propre identité.

Les pass-through vers des URL arbitraires sont ce que les équipes regretteront le plus, parce que chaque route amont doit alors être déclarée, relue et inscrite sur une liste d’autorisation, et que « juste relayer cette URL » attend un changement. L’exemple des métadonnées chez Wiz justifie ce prix.

L’avis de la CVE-2026-59822 dit qu’un échec de vérification de clé était remplacé par un objet d’authentification vide pour laisser passer un jeton OAuth amont ; tout repli d’authentification saute donc aussi. L’analyse de WorkOS sur trois bugs d’authentification MCP énonce la règle que j’adopterais telle quelle : « Never substitute a default identity or an empty auth object. » Si l’OAuth amont est exigé, c’est une route à part, avec sa propre validation.

Je garderais aussi l’exécution d’outils MCP hors de la passerelle de modèles : les outils qui écrivent relèvent de la couche d’actions, avec une validation liée aux paramètres exacts et aux droits de l’utilisateur, ce que détaille la liste de contrôle MCP pour l’accès en écriture.

Séparer le plan d’administration du plan de données

Une faille sur le chemin des données ne devrait pas atteindre l’API de gestion, et là où les deux partagent un port elle le peut, par le même processus et le même contrôle fondé sur le chemin : l’injection SQL arrivait par n’importe quelle route LLM, et la faille Starlette déjoue les contrôles fondés sur le chemin.

La page de durcissement de WSO2 donne une image honnête d’un défaut. Le contrôleur et le moteur de politiques ont chacun un serveur d’administration qui exporte la configuration ; le chart Helm livre allowed_ips: ["*"] pour les deux, trop large pour un cluster de l’aveu même de la page ; l’API de gestion peut lire et réécrire chaque fournisseur LLM, chaque proxy et chaque politique de la passerelle. Son conseil est de resserrer les plages et de laisser les ports d’administration hors des Services. J’irais plus loin : un port distinct, dans un réseau sans route depuis le plan de données, authentifié par votre fournisseur d’identité, une configuration modifiée par un pipeline relu, pas par une console. Le coût : une seconde entrée, une procédure de secours, et des administrateurs qui ne peuvent pas réparer la production depuis l’interface à minuit.

Comment tester qu’une passerelle refuse plutôt que de laisser passer ?

Cinq vérifications, une après-midi de travail :

  1. Envoyez une valeur Authorization: Bearer inventée sur chaque route, routes MCP et pass-through comprises, et attendez un refus, pas une session.
  2. Démarrez la passerelle sans clé maître, puis avec la valeur par défaut documentée, et envoyez une requête. Wiz rapporte qu’avant le correctif, sans clé maître chaque requête passait pour celle d’un administrateur, et que sk-1234 restait la valeur par défaut des installations Docker Compose et pip. La seule réponse acceptable est un refus.
  3. Depuis le réseau du plan de données, ouvrez une connexion vers le port de gestion et attendez l’absence de route, pas une page de connexion.
  4. Depuis le processus de la passerelle, demandez 169.254.169.254/latest/api/token, puis les identifiants du rôle. Sur un pod EKS aux métadonnées restreintes, attendez l’absence de réponse ; sur une instance EC2 avec un rôle d’instance, des identifiants pour les profils Bedrock approuvés et rien d’autre.
  5. Avec l’identifiant d’un tenant, envoyez l’identifiant de modèle d’un autre tenant dans le corps puis dans un en-tête, et attendez un refus.

Une passerelle qui passe les cinq peut encore être compromise. Elle a moins à livrer.

En pratique

Sur la plateforme d’ENSO, j’ai conçu une passerelle IA centrale comme chemin d’accès unique à Amazon Bedrock, avec des profils d’inférence limités à l’UE imposés à toute l’organisation via une SCP, le filtrage des PII par Guardrails et un routage des modèles qui isole les produits de leur cycle de vie. La passerelle est un élément d’une plateforme partagée et multi-tenant qui alimente quatre capacités produit ; l’architecture complète est décrite dans l’étude de cas ENSO, et ce type de passerelle fait partie du service de plateforme LLM d’entreprise.

Compromis et limites

Un rôle IAM supprime la clé permanente, pas la session. Une session volée fonctionne jusqu’à expiration, dans les limites de la politique du rôle et de la SCP, et on la prélève dans le processus ou sur le service de métadonnées : les règles IMDS et de sortie réseau ci-dessus ne sont pas des options. Il ne fait rien pour un fournisseur sans identité de charge de travail, et la passerelle mince est moins commode ; ses utilisateurs le diront.

Les correctifs comptent toujours. Chaque fiche du catalogue fixait une échéance dans les deux semaines suivant l’inscription, et chacune des quatre avait un correctif avant son inscription. Une passerelle mince achète une perte plus petite le temps de corriger, pas le droit d’attendre.

Le catalogue montre qu’il y a eu exploitation, pas à quelle fréquence ni chez qui. Je n’ai ni audité ni fait tourner LiteLLM ; ceci n’est pas un verdict sur ce projet ni sur un éditeur, mais sur ce qu’une passerelle auto-hébergée ou partagée détient, et sur ce dont elle peut se passer.

Questions fréquentes

LiteLLM est-il sûr en production ?

Trois failles LiteLLM ont été inscrites comme exploitées par la CISA en 2026, chacune corrigée avant l’inscription : la question est donc votre vitesse de correction et votre exposition, pas le projet. Je ne l’ai pas audité. Si vous l’exploitez : corrigez, remplacez la clé par défaut, bloquez les routes MCP inutilisées, restreignez métadonnées et sortie.

Une passerelle IA doit-elle stocker des clés API ?

Seulement quand le fournisseur n’offre aucune identité de charge de travail. Sur Amazon Bedrock, une passerelle peut appeler avec un rôle IAM : aucune clé de fournisseur à voler, seulement une session qui expire et que les politiques du compte plafonnent. Quand une clé est inévitable, lisez-la à l’appel dans un gestionnaire de secrets, une par tenant, plafonnée et renouvelée.

Comment sécuriser une passerelle LLM ?

Détenez moins : un rôle cloud plutôt que des clés de fournisseurs. Coupez les fonctions qui exécutent du code fourni par l’appelant ou relaient des requêtes vers des URL arbitraires. Isolez l’API de gestion sur son propre réseau. Restreignez métadonnées et sortie. Puis testez que jeton inventé, clé maître absente et nom de modèle d’un autre tenant sont refusés.

Qu’est-ce que le catalogue KEV de la CISA, et pourquoi le suivre pour les outils IA ?

La liste des failles dont l’agence américaine de cybersécurité a la preuve qu’elles sont exploitées, chacune avec une échéance pour les administrations fédérales. Il ne classe rien et ne compte aucune attaque. Trois entrées LiteLLM entre mai et septembre 2026 en font un signal précoce et peu coûteux pour l’infrastructure IA.

Sources