Flowise CVE-2026-40933 : importer un chatflow partagé suffit pour une RCE
L'analyse d'Obsidian Security du 28 mai 2026 montre comment le nœud Custom MCP de Flowise transforme une config MCP stdio en exécution de code côté serveur — et comment le simple import d'un chatflow partagé peut la déclencher, sans sauvegarde ni exécution.
De quoi s’agit-il ?
Flowise est un constructeur open-source populaire, en glisser-déposer, de workflows LLM et d’agents IA (plus de 52k étoiles GitHub). L’un de ses blocs est le nœud Custom MCP, qui permet à un chatflow de se connecter à un serveur Model Context Protocol à l’aide d’une configuration JSON fournie par l’utilisateur.
CVE-2026-40933 — « Flowise: Authenticated RCE Via MCP Adapters », publiée dans la GitHub Advisory Database le 16 avril 2026 (GHSA-c9gw-hvqq-f33r) — couvre le fait qu’une config Custom MCP utilisant le transport stdio fait lancer par le serveur Flowise n’importe quelle commande nommée dans la config, sans sandbox. Le 28 mai 2026, Obsidian Security a publié une analyse détaillée mettant en lumière l’aspect le plus dérangeant : un attaquant n’a pas besoin de convaincre une victime d’exécuter quoi que ce soit. Importer un chatflow partagé peut suffire à déclencher l’exécution. La sévérité revue par GitHub est critique ; le vecteur CVSS 3.1 publié est AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Les versions affectées sont flowise et flowise-components <= 3.0.13 ; l’avis indique le correctif en 3.1.0.
Comment ça marche
Le transport MCP stdio est, par conception, une primitive d’exécution de code : le client reçoit une command, des args optionnels et un env, puis lance cette commande comme processus enfant pour échanger du JSON-RPC sur l’entrée/sortie standard. Lorsque ce qui contrôle la config est un utilisateur peu fiable — ou un artefact importé — cette primitive devient une exécution de code arbitraire sur l’hôte.
Flowise a ajouté une couche de validation des entrées (CUSTOM_MCP_SECURITY_CHECK) qui autorise une poignée de lanceurs (node, npx, python, python3, docker), bloque les motifs de traversée et supprime les métacaractères shell. Le problème, documenté à la fois par l’avis GitHub et par Obsidian, est qu’un lanceur autorisé combiné à un argument qui exécute du code exécute quand même du code. Conceptuellement :
{
"command": "<allowlisted-launcher>", // passe l'allowlist de commandes
"args": ["<flag-that-evaluates-code>", "<REDACTED>"]
}
Les payloads exacts sont publics dans l’avis et l’analyse des chercheurs ; ils ne sont volontairement pas reproduits ici. Le point est structurel : la validation des entrées réduit les chemins évidents vers l’exécution mais ne supprime pas la capacité sous-jacente, car un comportement malveillant peut s’exprimer dans l’espace d’entrée valide de la fonctionnalité.
L’escalade « 1-clic » est la véritable nouveauté. Le nœud Custom MCP de Flowise possède un menu déroulant « Available Actions » qui énumère les outils exposés par un serveur MCP configuré. Avec stdio, énumérer les outils signifie démarrer la commande configurée — et cette énumération se déclenche dès que le chatflow importé s’affiche sur le canevas. Ainsi, une victime qui importe un chatflow partagé « prometteur » pour voir ce qu’il fait peut déclencher une exécution côté serveur avant toute sauvegarde ou exécution, sans aucune demande d’autorisation. Obsidian l’a testé sur Flowise 3.1.2 et rapporte que le durcissement par validation restait contournable à cette version.
C’est l’instance « plateforme d’agents » d’un schéma plus large que nous avons couvert : les prompts et configs qui deviennent des shells. Ici, l’entrée non fiable n’est pas un prompt mais un fichier de workflow partagé.
Pourquoi c’est important
Flowise se situe généralement à la couche d’orchestration, raccordé à des bases de données, des clés d’API et des comptes cloud. Une exécution de code dans ce processus signifie que chaque identifiant stocké est lisible et chaque service connecté est joignable — dans les déploiements conteneurisés, le processus tourne souvent en root, donc le rayon d’impact est tout le conteneur et tout ce qu’il peut atteindre.
L’exposition n’est pas théorique. Une faille Custom MCP antérieure et distincte — CVE-2025-59528 (CVSS 10.0, une injection JavaScript via le constructeur Function(), corrigée en 3.0.6) — a vu sa première exploitation dans la nature le 6 avril 2026, selon VulnCheck, avec environ 12 000 à 15 000 instances Flowise exposées sur Internet à ce moment-là. La même classe de nœud a désormais produit plusieurs CVE critiques et des attaques actives. Flowise Cloud n’est pas affecté car stdio MCP y est désactivé ; ce sont les déploiements auto-hébergés qui présentent le risque.
Défenses
- Désactivez
stdioMCP si vous n’en avez pas besoin. DéfinissezCUSTOM_MCP_PROTOCOL=sse. Obsidian qualifie ceci de mitigation la plus efficace ; elle supprime la primitive d’exécution au lieu d’essayer de la filtrer. - Ne vous reposez pas sur la seule validation des entrées.
CUSTOM_MCP_SECURITY_CHECKest activé par défaut mais présente des contournements documentés. Traitez-le comme une défense en profondeur, pas comme la frontière. - Mettez à jour, puis vérifiez. Quittez
flowise/flowise-components<= 3.0.13; l’avis indique 3.1.0 comme correctif. Confirmez aussi que vous êtes au-delà de 3.0.6 pour fermer CVE-2025-59528. Retestez que votre config n’autorise plus les combinaisons lanceur + flag d’exécution de code. - Considérez les chatflows importés comme du code non fiable. Un fichier JSON de chatflow partagé peut embarquer une config MCP qui s’exécute à l’import. Examinez les chatflows avant de les importer, et n’importez jamais depuis des sources inconnues sur un serveur qui détient de vrais identifiants.
- Gardez Flowise hors d’Internet. Placez-le derrière une authentification et un VPN/allowlist. Les décomptes d’instances exposées ci-dessus expliquent pourquoi les scanners les trouvent si vite.
- Isolez et appliquez le moindre privilège au runtime. Exécutez Flowise dans un conteneur sandboxé sous un utilisateur non-root, avec filtrage des sorties réseau et identifiants à portée limitée, afin qu’un événement d’exécution de code MCP soit contenu plutôt que catastrophique.
Statut
| Élément | Référence | Date | Notes |
|---|---|---|---|
| Avis CVE-2026-40933 (GHSA-c9gw-hvqq-f33r) | GitHub Advisory Database | 2026-04-16 | RCE authentifiée via adaptateurs MCP ; affecte <= 3.0.13 ; corrigé en 3.1.0 ; CWE-78 |
| Analyse Obsidian Security (RCE à l’import, 1-clic) | Obsidian Security | 2026-05-28 | L’énumération à l’import déclenche l’exécution ; validation contournable en 3.1.2 |
CVE-2025-59528 (injection Function() Custom MCP) | GitHub Advisory Database / NVD | 2025-09 → corrigé 3.0.6 | CVSS 10.0 ; faille sœur dans le même nœud |
| Exploitation dans la nature de CVE-2025-59528 | VulnCheck via CSO Online | 2026-04-06 | ~12k–15k instances exposées ; première exploitation observée |
Le cadrage qui compte : avec stdio MCP, quiconque influence la config obtient une exécution de code, et sur une plateforme partagée cela inclut un fichier de chatflow que quelqu’un importe. Filtrer les arguments réduit le chemin ; seuls la désactivation de la primitive ou le sandboxing du runtime le ferment.
Sources
- → https://www.obsidiansecurity.com/blog/when-is-stdio-mcp-actually-a-vulnerability
- → https://github.com/advisories/GHSA-c9gw-hvqq-f33r
- → https://www.csoonline.com/article/4155680/hackers-exploit-a-critical-flowise-flaw-affecting-thousands-of-ai-workflows.html
- → https://github.com/advisories/GHSA-3gcm-f6qx-ff7p