Flowise AI Agent Builder : Vulnérabilité Critique RCE CVSS 10.0
Origines et historique
Flowise est un projet open source pensé comme une boîte à outils pour créer des agents conversationnels et orchestrer des flux de traitement de données. L'idée est simple et puissante: assembler des blocs fonctionnels pour construire des agents, un peu comme on assemble des séquences dans un logiciel de montage vidéo. Cette flexibilité explique en grande partie l'adoption rapide de l'outil par des équipes de développement et de recherche.
Un composant précis, le nœud CustomMCP, a attiré l'attention des chercheurs en sécurité. Ce nœud permet d'ajouter des connexions à des ressources externes via des configurations fournies par l'utilisateur. Des analyses techniques menées par VulnCheck détaillent comment une mauvaise gestion des entrées dans ce nœud peut mener à l'exécution de code arbitraire à distance, validée sous la référence CVE-2025-59528¹. La vulnérabilité a reçu la note maximale de 10.0 au barème CVSS, ce qui traduit la facilité d'exploitation depuis le réseau et l'impact total sur la confidentialité, l'intégrité et la disponibilité telle que consignée par la base NVD³.
Parallèlement, des recherches et rapports d'actualité ont identifié un grand nombre d'instances Flowise accessibles sans protections adaptées. Plus de 12 000 déploiements exposés ont été repérés, souvent utilisés pour des tests ou des démonstrations mais laissés sans authentification suffisante². On peut comparer la situation à des services d'administration laissés ouverts: l'outil lui-même n'est pas malveillant, mais sa configuration et son exposition créent une cible de choix pour des attaquants opportunistes.
Fonctionnement technique
Mécanique de la vulnérabilité
La porte d'entrée exploitée par CVE-2025-59528 se situe dans la gestion des configurations du nœud CustomMCP. Lorsque Flowise reçoit et interprète des paramètres envoyés par l'utilisateur, il n'applique pas de validation stricte ni de contrôle d'intégrité sur certains champs critiques. Un attaquant peut donc transmettre une charge utile sous forme de configuration qui sera interprétée et exécutée par le moteur de Flowise. Concrètement, le code malveillant s'exécute avec les privilèges du processus Flowise, ce qui permet d'enchaîner des actions telles que exfiltration de données, déploiement d'outils de maintien d'accès, ou modification des flux pour propager l'attaque¹.
Les environnements de déploiement courants - containers Docker, orchestrateurs Kubernetes ou machines virtuelles - n'offrent pas automatiquement une barrière contre ce type d'exploitation. Beaucoup d'instances sont exposées par défaut sur Internet sans authentification renforcée, ce qui augmente fortement la surface d'attaque².
Vecteurs d'attaque exploitables
- Interfaces Web publiques: une interface d'administration Flowise accessible depuis Internet permet d'envoyer des configurations malveillantes via le navigateur ou des requêtes HTTP.
- API non sécurisées: des endpoints REST non protégés peuvent être utilisés pour modifier directement des nœuds et injecter des paramètres dangereux.
- Pipelines CI/CD: si des artefacts de configuration transitent par des systèmes d'intégration continue sans contrôle, des configurations corrompues peuvent être déployées automatiquement, transformant un processus fiable en vecteur d'injection.
Exemple simplifié d'exploitation:
- Repérage d'une instance Flowise exposée via un scan ou un moteur de surface d'attaque.
- Envoi d'une requête POST contenant une configuration malveillante ciblant le nœud CustomMCP.
- Flowise parse la configuration et exécute le contenu dangereux.
- L'attaquant obtient une exécution de commandes sur l'environnement, puis installe des outils de persistance.
Contre-mesures techniques immédiates
- Appliquer la mise à jour corrigée de Flowise dès que possible, ou les correctifs fournis par les mainteneurs.
- Si la mise à jour n'est pas immédiatement faisable, désactiver le nœud CustomMCP pour éviter toute configuration dynamique jusqu'à ce qu'un patch soit installé.
- Restreindre l'accès à l'interface et aux API: placer un reverse proxy ou une passerelle d'authentification en front, obliger l'utilisation de MFA pour les comptes administrateurs.
- Valider et filtrer toutes les entrées côté serveur: refus explicite des formats non attendus, listes blanches pour les champs structurés, désactivation des fonctionnalités d'exécution de code dynamique.
- Limiter les privilèges du processus Flowise: exécuter l'application avec un compte non privilégié, mettre en place des contrôles de confinement (AppArmor, SELinux, politiques Kubernetes).
Études de cas
Cas 1: exploitation en production - compromission de serveurs d'IA
Des incidents documentés montrent que des instances Flowise exposées ont été compromise, permettant aux intrus d'exécuter des commandes et d'installer des outils de maintien d'accès. Des clés d'API ont été exfiltrées, puis utilisées pour générer des coûts cloud frauduleux par des appels aux plateformes d'IA commerciale¹. Ces compromissions illustrent comment une outil de prototypage peut devenir un point d'appui pour des opérations financières malveillantes.
Cas 2: larges scans et mise à nu d'instances - cartographie d'exposition
La découverte de plus de 12 000 instances accessibles montre un problème de maturité opérationnelle: beaucoup d'équipes déploient des démonstrateurs ou des environnements de staging en production sans durcir l'accès. Des scans automatisés repèrent rapidement ces cibles et permettent des attaques opportunistes à grande échelle². Les conséquences vont de la fuite d'exemples de données utilisateur à la récupération d'informations sensibles présentes dans des projets.
Cas 3: vecteur de distribution pour charges utiles secondaires
Après exploitation, les attaquants ont fréquemment déployé des charges utiles secondaires, par exemple des mineurs de cryptomonnaies ou des agents de botnet. L'avantage pour un attaquant est double: monétiser l'accès par du minage et disposer d'une infrastructure compromise pour lancer d'autres attaques. Les hôtes compromis servent alors d'outils au service d'acteurs malveillants, étendant l'impact initial.
Perspectives
Évolutions techniques attendues
Les mainteneurs et la communauté open source travaillent à renforcer la sécurité de Flowise: durcissement par défaut des configurations, retrait ou limitation des fonctions qui permettent l'exécution dynamique de code, et introduction de contrôles de validation plus stricts pour les nœuds acceptant des entrées externes. Les intégrateurs devront préférer des images officielles et éviter des builds non audités.
Tendances en matière d'exploitation
L'automatisation des scans et l'offre d'outils d'exploitation dans les catalogues publics rendent l'exploitation d'une nouvelle vulnérabilité extrêmement rapide. Dès l'annonce d'une faille critique, le temps moyen avant la première exploitation active se réduit drastiquement. Cela impose une posture prompte: patcher vite, isoler les services exposés, et détecter les comportements anormaux plutôt que d'attendre une attaque manifeste.
Recommandations stratégiques pour les opérateurs
- Inventorier toutes les instances Flowise et vérifier l'accessibilité depuis Internet. Toute interface d'administration visible doit être considérée comme exposée et traitée en priorité.
- Appliquer les correctifs et éviter les images non officielles. Préférer des pipelines CI contrôlés et signer les artefacts.
- Segmenter le réseau: limiter la portée des interfaces de gestion aux segments de supervision et aux VPN internes.
- En cas de compromission potentielle, révoquer et faire tourner toutes les clés et secrets associés, puis procéder à une analyse forensique.
- Mettre en place une surveillance continue des logs et des métriques: alertes sur exécutions anormales, pics d'utilisation CPU mémoire ou trafic sortant inhabituel.
Checklist opérationnelle
- Identifier les endpoints Flowise exposés (outils suggérés: nmap, Shodan) et isoler ceux qui sont critiques.
- Appliquer le correctif officiel ou désactiver le nœud CustomMCP si nécessaire.
- Forcer la rotation des clés API et révoquer les tokens suspects.
- Inspecter les logs pour détecter toute activité suspecte ou exfiltration de données.
- Restaurer les systèmes à partir d'images de confiance et reprovisionner les environnements affectés.
