Les attaquants adaptent leurs méthodes aux infrastructures d’IA, au lieu de se contenter de les scanner comme n’importe quel autre service web.
Wiz Threat Research a indiqué que son opération de honeypots, menée pendant 90 jours, avait capturé des attaques persistantes contre LiteLLM, des serveurs Model Context Protocol (MCP), LangChain, Flowise, Langflow, OpenWebUI, Node-RED et d’autres services d’IA. Cette activité comprenait l’exploitation de LiteLLM, du minage de cryptomonnaies, des injections de prompts à l’aveugle et des tentatives visant à extraire des identifiants de systèmes d’IA en fonctionnement.
Les passerelles d’IA peuvent contenir des clés de fournisseurs de modèles, des autorisations cloud et des connexions à des systèmes internes via MCP. Wiz a mené des recherches en honeypot qui ont montré que les attaquants ciblaient ces relations après l’accès initial, tandis que d’autres intrusions récentes ont montré l’IA utilisée dans des attaques réelles à des fins de reconnaissance, d’exploitation, de vol d’identifiants et de prise de décision après compromission.
Les failles de LiteLLM ouvrent deux voies d’attaque
LiteLLM achemine les requêtes entre plusieurs fournisseurs de grands modèles de langage, ce qui en fait une cible intéressante lorsque les connexions MCP exposent des outils supplémentaires ou des ressources internes.
L’une des voies d’attaque impliquait CVE-2026-59822, une faille critique de contournement de l’authentification affectant les versions de LiteLLM antérieures à 1.84.0. Une mauvaise gestion du relais OAuth2 permettait à un jeton Bearer arbitraire d’atteindre les fonctionnalités MCP configurées sans clé LiteLLM valide. Wiz a observé des attaquants utiliser des jetons d’un seul caractère pour sonder les services exposés. Des recherches similaires sur le vol d’identifiants via MCP ont montré comment des intégrations compromises pouvaient exposer des jetons OAuth et des services SaaS connectés.
Par ailleurs, les attaquants ont exploité CVE-2026-42271, une faille d’exécution de commandes authentifiée affectant les versions de LiteLLM allant de 1.74.2 aux versions antérieures à 1.83.7. Les points de terminaison de test MCP pouvaient lancer des commandes contrôlées par les attaquants en tant que sous-processus sur l’hôte LiteLLM. Dans les honeypots de Wiz, les attaquants ont utilisé cette faille pour lancer un téléchargeur Python et installer un mineur de cryptomonnaies.
Le mineur s’exécutait comme un processus détaché tandis que son répertoire de préparation était supprimé, réduisant les traces laissées sur le disque. La campagne plus large comprenait également des tentatives d’injection de prompts à l’aveugle contre d’autres frameworks d’IA, les attaquants utilisant des requêtes DNS sortantes pour déterminer si les commandes s’exécutaient lorsque leur résultat n’était pas directement visible.
Les passerelles d’IA concentrent les risques
La priorité immédiate consiste à corriger les vulnérabilités connues tout en réduisant ce à quoi une passerelle compromise peut accéder. Les outils de développement de l’IA, notamment les serveurs MCP, font de plus en plus partie de la chaîne d’approvisionnement logicielle et peuvent donner accès au code, aux identifiants et aux environnements CI/CD.
Les entreprises devraient :
- Corrigez rapidement LiteLLM. Passez à la version 1.84.0 ou ultérieure et vérifiez que les applications dépendantes n’imposent pas de versions vulnérables.
- Restreignez les points de terminaison MCP et administratifs. Désactivez les routes inutilisées, limitez les interfaces de test aux utilisateurs de confiance et évitez toute exposition publique superflue.
- Placez les passerelles derrière des contrôles réseau. Utilisez des reverse proxies, des WAF, des VPN ou des répartiteurs de charge privés afin de réduire les accès directs.
- Appliquez le principe du moindre privilège et la segmentation. Limitez les clés de fournisseurs, les rôles cloud, les comptes de service et les autorisations des outils MCP, et isolez les systèmes d’IA des infrastructures sensibles.
- Contrôlez le trafic sortant. Restreignez les connexions DNS et HTTP inutiles et déclenchez des alertes en cas de rappels inhabituels, de téléchargements de charges utiles ou d’énumération de modèles.
- Recherchez les abus de processus et d’identifiants. Examinez les processus enfants suspects, les répertoires de préparation supprimés, les requêtes MCP anormales et les tentatives de récupération d’identifiants en mémoire.
- Testez les plans de réponse aux incidents pour les infrastructures d’IA. Validez l’isolement, la rotation des identifiants, l’examen des services MCP, l’analyse des journaux cloud et API, ainsi que les vérifications des accès en aval.
Pour les équipes de sécurité, la compromission d’une passerelle devrait entraîner l’examen de chaque identifiant, connexion MCP et service en aval auxquels elle pouvait accéder — et pas seulement de l’hôte LiteLLM lui-même.
Wiz a également observé des attaquants interroger le processus Python de LiteLLM en cours d’exécution pour en extraire la clé principale et identifier les backends de modèles disponibles. Les défenseurs doivent tenir compte des identifiants et des connexions exposés par la mémoire et l’état d’exécution, et pas uniquement des fichiers présents sur le disque.
Les passerelles d’IA doivent être considérées comme des infrastructures à privilèges. Limiter leur exposition, leurs autorisations et leur connectivité peut réduire la progression d’un attaquant après une compromission.
En savoir plus : les arrestations récentes de TeamPCP montrent comment la compromission d’outils de développement de confiance peut conduire à des vols d’identifiants à grande échelle dans toute la chaîne d’approvisionnement logicielle.