Intrusions dans l'infrastructure IA : vol de clés et minage sur les passerelles LLM

De quoi s’agit-il ?

Le 26 août 2026, Microsoft Security Research a publié l’analyse d’intrusions visant trois charges de travail IA distinctes : une passerelle LiteLLM, un déploiement RAGFlow et un environnement de workflows Kestra. Le document est signé Yash Gund et Sumith Maniath et s’appuie sur la télémétrie Microsoft Defender collectée sur les hôtes compromis.

Ce qui rend cette publication intéressante n’est pas la sophistication — il y en a peu. Les voies d’entrée diffèrent selon le produit, mais les objectifs sont identiques dans les trois cas, et parfaitement classiques : récupérer des identifiants, établir une persistance, puis monétiser l’hôte avec un mineur de cryptomonnaie. Aucun acteur n’est nommé, aucune attribution étatique n’est avancée. C’est de la criminalité de masse qui découvre une nouvelle catégorie de cibles exposées.

Cette cible, Microsoft l’appelle un point de contrôle : passerelles, plateformes de récupération et services d’orchestration s’intercalent désormais entre les utilisateurs, les applications, les données et les modèles — et concentrent de ce fait clés de fournisseurs de modèles, chaînes de connexion aux bases, configuration des locataires et privilèges d’exécution dans un seul et même runtime.

Comment ça marche

La passerelle (LiteLLM). L’accès initial est évalué avec un haut niveau de confiance comme une exploitation de la surface exposée de la passerelle : une faille d’exécution de commandes authentifiée dans les endpoints de test MCP stdio, que des travaux publics de Horizon3.ai chaînent avec un contournement de validation d’en-tête Host dans Starlette pour atteindre l’exécution de code non authentifiée sur les déploiements vulnérables. La suite est le plus instructif. La passerelle tourne en PID 1 dans son conteneur : la charge utile a donc lu /proc/1/environ et l’a filtré sur des mots-clés comme master, API key, token et password. Un one-liner Python autonome a ensuite extrait DATABASE_URL de ce même environnement, s’est connecté à l’instance PostgreSQL sous-jacente et a vidé les tables de modèles et de clés virtuelles. La sortie a été encodée en base64 et exfiltrée par petits fragments vers des points de rappel hors bande. La persistance est passée par la modification des clés SSH autorisées, des noms de services usurpés et des attributs de fichiers immuables ; une réécriture de crontab supprimait au passage les mineurs concurrents avant d’installer le sien.

La plateforme de récupération (RAGFlow). Microsoft indique explicitement avoir une faible confiance quant à la faille précise ayant permis l’exécution de code : les chemins de code concernés s’exécutent dans le processus Flask de RAGFlow, et la télémétrie endpoint n’a pas pu isoler le point d’exécution. Plusieurs candidats publiquement documentés existent, dont des injections de gabarits dans le générateur de prompts et le composant de workflow d’agent, une traversée de répertoire dans un parseur, et un contournement de bac à sable. C’est le comportement post-exploitation qui compte : l’attaquant a déposé un hook Python caché sous l’arborescence applicative, modifié le chemin d’import pour qu’il soit chargé avec le service, et enveloppé le flux de configuration LLM du locataire. Le hook ne volait pas les clés stockées — il capturait les identifiants de fournisseurs au moment où les administrateurs les saisissaient ensuite, pour les configurations OpenAI, Azure, Anthropic et Gemini, en supprimant les erreurs pour que la configuration paraisse réussir. Aucun mineur dans ce cas : l’objectif était purement l’interception d’identifiants.

L’orchestrateur (Kestra). L’accès initial est évalué avec un haut niveau de confiance comme un contournement d’authentification. La cause racine est un bug d’application web d’école, sans la moindre IA dedans : le filtre d’authentification mettait l’endpoint de configuration public en liste blanche via une comparaison de suffixe (endsWith("/configs")) plutôt qu’une comparaison de chemin exacte. Comme Kestra adresse ses ressources par des segments de chemin choisis par l’appelant — espace de noms, identifiant de flux — tout chemin se terminant par ce segment passait à côté du Basic Auth. Assez pour créer et exécuter un workflow, et Kestra embarque des plugins d’exécution de scripts par défaut. S’ensuivent une exécution de shell depuis la lignée du worker, un accès au socket Docker pour énumérer les tableaux d’environnement des autres conteneurs accessibles via ce socket monté, puis XMRig contre un pool Monero.

Microsoft note également que plusieurs charges utiles présentaient des caractéristiques souvent associées à du code assisté ou généré : imports organisés, gestion explicite des délais d’attente, replis de dépendances, gestion défensive des exceptions, commentaires explicatifs. L’éditeur présente cela prudemment comme une observation sur l’outillage, pas comme un élément d’attribution, et refuse d’en tirer une conclusion sur la paternité du code. Nous le rapportons aux mêmes conditions.

Pourquoi c’est important

Le rayon d’action d’une passerelle IA est plus large que ce que reflètent la plupart des inventaires. Un seul proxy compromis livre la clé maîtresse, l’ensemble des clés virtuelles par locataire qu’il a émises, et une chaîne de connexion qui mène ailleurs. La facture du fournisseur de modèle est le moindre des problèmes : ces clés ouvrent en général l’accès à tout ce que l’organisation a branché sur le modèle.

Le cas RAGFlow est celui qu’il faut retenir. La rotation des identifiants est la réponse standard à une suspicion de fuite de clé — or, face à un hook installé dans le flux de configuration, la rotation alimente activement l’attaquant. Chaque clé fraîchement émise est capturée à l’instant de sa saisie. Toute réponse à incident sur une plateforme de récupération ou une passerelle doit donc établir que l’arborescence applicative est saine avant qu’un nouveau secret ne s’en approche.

Enfin, la faille Kestra rappelle que la pile IA absorbe de l’infrastructure généraliste plus vite qu’elle ne la fait réauditer. Un contrôle d’autorisation par suffixe est un bug que la communauté sécurité web comprend depuis vingt ans. Il devient critique ici parce que ce composant se trouve désormais devant des identifiants de modèles et des runtimes de conteneurs.

Défenses

Inventoriez et fermez les surfaces d’administration exposées. Les interfaces d’administration des passerelles, plateformes RAG et orchestrateurs ne doivent pas être joignables depuis Internet. C’est le contrôle unique qui aurait évité les trois intrusions.

Corrigez les composants cités. Le contournement d’authentification de Kestra est corrigé en 1.0.45 et 1.3.21 ; considérez toute version antérieure comme exposée à une RCE non authentifiée. Appliquez les versions à jour de LiteLLM et RAGFlow ainsi que les correctifs des frameworks amont.

Sortez les clés de fournisseurs de l’environnement du processus. La lecture de /proc/1/environ ne paie que si les clés s’y trouvent. Injectez les secrets depuis un coffre géré au moment de l’appel, émettez des clés virtuelles par équipe avec plafonds de dépense plutôt qu’une clé maîtresse partagée, et faites tourner tout ce qui a résidé sur une instance exposée — après le contrôle d’intégrité ci-dessous.

Appliquez le moindre privilège entre passerelle et base. Faites tourner le proxy sous un compte de service dédié, restreignez ses droits aux objets strictement nécessaires, et placez la base derrière un endpoint privé avec des règles de pare-feu restrictives. Vider une table de clés virtuelles ne devrait pas faire partie de ce que le rôle de la passerelle peut faire.

Passez l’egress en deny-by-default. Mettez en liste blanche les endpoints des fournisseurs de modèles et des services nécessaires ; bloquez les connexions directes vers des adresses IP brutes et des ports non standard ; faites transiter le trafic autorisé par un proxy filtrant par FQDN. Journalisez et filtrez le DNS : les balises encodées en sous-domaines et les rappels hors bande y sont visibles avant tout le reste.

Durcissez le runtime hôte. Montez les répertoires temporaires en non exécutable quand c’est opérationnellement possible, alertez sur toute exécution depuis un chemin inscriptible par tous, et surveillez les modifications des entrées cron, des fichiers authorized_keys et des attributs d’immuabilité.

Vérifiez l’intégrité applicative avant de faire tourner les identifiants. Comparez l’arborescence déployée et les chemins d’import à une image de référence, et traitez tout hook inattendu dans un flux de configuration d’identifiants comme un bloqueur de rotation.

Détectez sur la corrélation, pas sur l’événement isolé. Aucune de ces étapes n’est individuellement alarmante. Le signal, c’est la chaîne : un shell ou un interpréteur lancé depuis l’application, puis un accès à des secrets, puis un dépôt de charge utile dans un répertoire temporaire, puis un rappel sortant. La recommandation propre à Microsoft est de surveiller les charges de travail IA selon leur rôle de plan de contrôle plutôt que comme des applications isolées — et de traiter toute activité de type SSRF sur une plateforme de récupération comme un précurseur, puisque dans le cas RAGFlow l’exécution de code a suivi plusieurs jours plus tard.

Status

Élément	Référence	Date	Notes
Publication d’investigation Microsoft	Microsoft Security Research	2026-08-26	Trois charges de travail : passerelle LiteLLM, RAGFlow, Kestra. Aucune attribution d’acteur
Exécution de commandes MCP stdio LiteLLM	CVE-2026-42271 / GHSA-v4p8-mg3p-g94g	—	Exécution authentifiée ; accès initial à haute confiance dans le cas de la passerelle
Contournement de validation d’en-tête Host Starlette	CVE-2026-48710	—	Chaîné par les travaux publics de Horizon3.ai pour atteindre une RCE non authentifiée
Failles candidates RAGFlow	CVE-2026-45312, CVE-2026-28797, CVE-2026-24770, CVE-2025-68700, CVE-2025-69286	—	Injection de gabarits, traversée de répertoire, contournement de bac à sable, accès aux comptes. Faible confiance — aucune confirmée
Contournement d’authentification Kestra	CVE-2026-49869	—	CVSS 10. Filtre par suffixe sur l’endpoint de configuration public ; corrigé en 1.0.45 et 1.3.21
Cadres de référence	OWASP LLM Top 10 (chaîne d’approvisionnement / agentivité excessive), MITRE ATT&CK T1190, T1552.001, T1496	2026	Exploitation d’application exposée → identifiants dans des fichiers → détournement de ressources

Date de publication de la source principale : 26 août 2026. Les niveaux de confiance de Microsoft varient selon les cas et sont reproduits ci-dessus tels que publiés — haute confiance sur les accès initiaux LiteLLM et Kestra, faible confiance sur le point d’exécution RAGFlow.