LiteLLM, RAGFlow et Kestra attaqués : les clés IA deviennent la cible

Le 26 août 2026, l’analyse de Microsoft Security Research a rendu publiques trois compromissions distinctes touchant une passerelle LiteLLM, un déploiement RAGFlow et un environnement Kestra exposés sur Internet. Les intrus ont recherché des identifiants, installé des mécanismes de persistance et, dans les cas LiteLLM et Kestra, détourné du calcul pour le minage de cryptomonnaie.

Il ne s’agit pas d’une attaque coordonnée attribuée à un même groupe, mais de trois chaînes d’intrusion rapprochées en raison de leur cible commune : des charges IA qui concentrent clés de fournisseurs, connexions aux bases et droits d’exécution. Un compte rendu indépendant publié le 27 août souligne cette concentration de secrets et de privilèges dans des outils encore parfois déployés sans les protections réservées aux infrastructures critiques.

Trois intrusions aux chemins différents

Pour LiteLLM, l’accès initial est évalué avec un niveau de confiance élevé comme une exploitation probable de la passerelle exposée. La séquence est compatible avec l’enchaînement de CVE-2026-42271, une exécution de commandes dans des fonctions de test MCP stdio, et de CVE-2026-48710, un contournement de validation de l’en-tête Host. Cette compatibilité ne prouve toutefois pas que les deux failles ont constitué le vecteur exact dans chaque environnement observé.

Depuis le processus LiteLLM, les attaquants ont consulté les variables d’environnement, notamment /proc/1/environ lorsque la passerelle occupait le PID 1 du conteneur. Ils pouvaient ainsi atteindre des clés de fournisseurs de modèles, la clé maîtresse LiteLLM, des identifiants d’interface et la chaîne de connexion PostgreSQL. L’accès à la base a ensuite servi à collecter des configurations de modèles et des clés virtuelles, tandis que des clés SSH, des tâches cron et des fichiers rendus immuables renforçaient la persistance.

Dans RAGFlow, une reconnaissance de type SSRF a précédé de plusieurs jours l’exécution de code dans le service. Aucun CVE précis n’est attribué à cette intrusion. Un hook Python caché modifiait le chemin de démarrage de l’application et enveloppait TenantLLM.insert() afin de capter les nouvelles clés OpenAI, Azure, Anthropic ou Gemini avec leurs métadonnées, puis de les exfiltrer vers une infrastructure externe.

Dans Kestra, l’accès initial est évalué comme probablement lié à CVE-2026-49869, un contournement d’authentification permettant de définir et de déclencher un workflow malveillant. Le worker Java a lancé un shell inversé ; le socket Docker monté dans l’environnement a ensuite permis d’énumérer les variables des conteneurs actifs. Les opérateurs ont également déployé XMRig et dirigé le mineur vers un pool Monero.

La chaîne d’attaque comparée

Les trois produits n’exposent pas les mêmes privilèges. Leur comparaison distingue le point d’entrée, les secrets accessibles, la persistance observée, le bénéfice recherché et le contrôle à traiter en priorité.

• LiteLLM — entrée : exploitation probable d’une passerelle publique. Secrets : clés de fournisseurs, clé maîtresse, clés virtuelles et connexion PostgreSQL. Persistance : clé SSH, cron et fichiers immuables. Monétisation : vol d’accès et minage. Contrôle prioritaire : fermer l’administration publique, corriger l’instance et révoquer tous les secrets accessibles au processus.
• RAGFlow — entrée : surface applicative exposée, après une reconnaissance compatible avec une SSRF, sans vulnérabilité confirmée. Secrets : nouvelles clés de fournisseurs et métadonnées de modèles. Persistance : hook chargé au démarrage et clé SSH ajoutée au conteneur. Monétisation : usage frauduleux possible des comptes compromis. Contrôle prioritaire : vérifier l’intégrité du chemin applicatif et révoquer les clés ajoutées depuis le début possible de l’infection.
• Kestra — entrée : création et exécution non autorisées d’un workflow. Secrets : variables d’environnement de plusieurs conteneurs via Docker. Persistance : maintien du mineur après la fermeture du shell avec nohup et collecte ultérieure via l’API KV. Monétisation : minage de Monero. Contrôle prioritaire : protéger l’API de workflow et retirer l’accès non indispensable au socket Docker.

Pourquoi les clés IA élargissent la compromission

Une passerelle LiteLLM peut disposer de plusieurs clés amont afin de router les requêtes vers différents fournisseurs. RAGFlow traite les identifiants au moment où un locataire configure ses modèles et relie ces modèles à des corpus documentaires. Kestra exécute des workflows susceptibles de communiquer avec des conteneurs, des bases, des services cloud et des API internes.

Ces composants fonctionnent donc comme des plans de contrôle, et non comme de simples serveurs applicatifs. Une exécution de commandes dans leur runtime peut ouvrir l’accès aux comptes de modèles, aux bases de configuration, aux secrets d’autres conteneurs ou à des capacités d’automatisation. Le minage rend l’intrusion visible par la consommation de processeur ; une clé exfiltrée peut, elle, rester exploitable après le nettoyage de l’hôte si elle n’est pas révoquée.

Réduire l’exposition et révoquer au bon périmètre

Le premier contrôle consiste à ne pas exposer directement les interfaces de gestion et d’orchestration. Dans son architecture de référence, la documentation AWS pour LiteLLM place l’accès public derrière CloudFront et AWS WAF, avant le répartiteur de charge et les conteneurs ECS ou EKS ; elle prévoit aussi le stockage des identifiants de fournisseurs dans AWS Secrets Manager.

Ce filtrage ne remplace ni l’authentification, ni les correctifs, ni le moindre privilège. Les ports d’administration doivent rester privés, les bases être isolées et les comptes de service limités aux ressources nécessaires. Des clés distinctes par équipe ou charge, avec des plafonds de dépense, réduisent aussi le rayon d’impact d’un identifiant volé.

Après une compromission, supprimer le mineur ne suffit pas. L’enquête doit couvrir les shells lancés par les processus LiteLLM, RAGFlow ou Kestra, les lectures de variables d’environnement, les modifications du code applicatif, les clés SSH, les tâches cron et l’usage du socket Docker. La révocation doit inclure les clés IA, mais aussi les chaînes de connexion, jetons cloud et secrets d’API visibles depuis les conteneurs atteints.

Le nombre de victimes et l’attribution restent inconnus

Les observations publiées ne précisent ni le nombre total d’organisations compromises, ni les versions exactes de chaque déploiement, ni une attribution commune. Le vecteur de RAGFlow demeure indéterminé ; pour LiteLLM et Kestra, les chemins d’accès initial sont des évaluations à haute confiance fondées sur la télémétrie et le contexte de vulnérabilités publiques, pas une certitude établie pour toute installation.

L’état actuel de l’enquête confirme néanmoins le point central du titre : les passerelles, plateformes RAG et orchestrateurs sont attaqués pour les secrets et les privilèges qu’ils agrègent. Les prochaines précisions attendues concernent l’étendue des victimes, les configurations touchées et l’éventuelle relation entre les infrastructures utilisées dans ces trois intrusions.

À lire aussi:

• Apple supprime plus de 200 postes : l’IA redistribue les équipes
• Suno limite les téléchargements : les morceaux IA deviennent traçables
• Les marques paient désormais les créateurs pour apparaître dans les réponses IA