IA no-code : la surface d'attaque cachée des pipelines LLM

CVE-2026-33017 exploitée en 20 heures. CVE-2025-34291 ajoutée au KEV CISA. CVE-2026-33309 à CVSS 10.0. Trois vulnérabilités critiques dans Langflow en moins de six mois. Ce n'est pas un accident de parcours — c'est le signal d'une nouvelle catégorie de risque que la grande majorité des équipes sécurité n'a pas encore cartographiée dans son modèle de menace.

Quand l'IA no-code envahit le SI sans passer par la DSI

Depuis 2024, les plateformes d'orchestration IA no-code ont connu une croissance exponentielle en entreprise. Langflow, Flowise, n8n avec ses nodes IA, Dify, Make.ai (ex-Integromat), Zapier AI, Relevance AI — la liste s'allonge chaque trimestre. Ces outils permettent à n'importe quelle équipe métier ou data de construire des pipelines LLM complexes en quelques heures, sans ligne de code : connecter GPT-4o à une base vectorielle Pinecone, brancher un agent IA sur des données Salesforce, automatiser la rédaction de contrats en RAG sur une base documentaire interne.

Le marché est considérable. Selon les données de Grand View Research, le marché global des plateformes d'orchestration IA d'entreprise était évalué à 2,1 milliards de dollars en 2025, avec une trajectoire de croissance annuelle composée (CAGR) de 38 % jusqu'en 2030. L'image Docker officielle de Langflow dépasse les 10 millions de pulls. Flowise compte plusieurs dizaines de milliers d'étoiles sur GitHub. Ces chiffres ne sont pas anecdotiques : ils représentent autant de déploiements potentiels dans des SI d'entreprise, dont beaucoup sans aucune supervision sécurité.

Le problème structurel est le suivant : ces outils sont massivement déployés sans passer par les processus de validation de la DSI ou du RSSI. Un data scientist installe Langflow sur un serveur Ubuntu en DMZ pour un PoC, et le PoC devient production six mois après sans validation sécurité. Une équipe marketing déploie n8n en self-hosted pour automatiser des workflows IA, sans passer par le comité d'approbation des nouvelles solutions logicielles. C'est le shadow IT de l'IA — et il est partout.

Les directions métier adorent ces outils pour des raisons légitimes : time-to-market réduit de semaines à heures, autonomie sans dépendance à l'équipe développement, interfaces visuelles intuitives. Ce sont exactement ces qualités qui posent problème du point de vue sécurité : moins de contrôle, moins de revue de code, moins de supervision, moins de maintenance. L'équipe qui déploie est rarement celle qui maintient, et la maintenance sécurité est la première victime de cette fragmentation.

La surface d'attaque que personne ne cartographie

Partons du code source de Langflow pour comprendre le problème à sa racine. Le vecteur d'exploitation de CVE-2026-33017 est dans l'endpoint POST /api/v1/build/{flow_id}/public_tmp. Ce endpoint reçoit du code Python dans le corps de la requête HTTP et le passe directement à la fonction native Python exec(). Sans sandbox. Sans restriction de modules importables. Sans validation du contenu soumis. C'est l'équivalent moderne de l'injection SQL des années 2000, mais avec une payload qui n'est pas du SQL — c'est du Python arbitraire avec accès au système de fichiers, au réseau, aux variables d'environnement, et à toute bibliothèque installée sur le serveur.

Ce n'est pas une erreur d'implémentation isolée commise par un développeur distrait — c'est le symptôme d'une architecture qui n'a pas été pensée pour opérer dans un environnement hostile. Ces plateformes ont été conçues pour la collaboration et la rapidité de prototypage, pas pour résister à des attaquants motivés. Les conséquences de cette philosophie de conception se retrouvent dans plusieurs dimensions de la surface d'attaque.

Les permissions excessives. La plupart des instances Langflow s'exécutent avec les droits de l'utilisateur système qui lance le processus — souvent root dans les déploiements Docker non sécurisés où l'option --user n'est pas utilisée, ou avec un compte ayant des droits larges sur le filesystem. Une RCE dans ce contexte donne à l'attaquant un accès illimité au serveur et potentiellement à toute la machine physique ou VM sous-jacente.

Les secrets dans les flows. Les flows Langflow stockent les credentials de connexion aux services externes directement dans leur configuration : clés API OpenAI avec les quotas associés (potentiellement des milliers d'euros par mois), clés Anthropic, tokens Google AI Studio, credentials de bases de données vectorielles (Pinecone, Weaviate, Chroma, Qdrant), tokens d'API Salesforce, Notion, HubSpot, Airtable. Une compromission du serveur Langflow est une compromission simultanée de l'ensemble de ces accès. Et une clé API LLM active représente une valeur économique directe pour un attaquant qui peut la revendre ou l'utiliser pour ses propres besoins, à vos frais.

L'exposition réseau par défaut. Langflow écoute par défaut sur 0.0.0.0:7860 — toutes les interfaces réseau, y compris les interfaces publiques si le serveur est dans un réseau mal configuré. Sans reverse proxy de type nginx avec authentification, sans rate limiting, sans restriction par IP. Les scanners Shodan et Censys indexent régulièrement des instances Langflow accessibles depuis Internet, certaines sans aucune authentification — les flows et les credentials qui y sont stockés sont librement consultables par quiconque tombe dessus.

L'absence de monitoring applicatif. La quasi-totalité des déploiements Langflow en entreprise n'intègrent pas de monitoring des appels API entrants, pas de détection d'anomalies sur les requêtes, pas d'alerte sur les patterns d'exploitation connus. Une attaque peut se dérouler en quelques secondes et passer complètement inaperçue pendant des jours, voire des semaines, avant que des indicateurs secondaires (pic de consommation LLM, connexions réseau suspectes) ne permettent une détection indirecte.

Le multi-tenant non isolé. Dans les déploiements partagés — Langflow hébergé par une ESN pour plusieurs clients, ou une instance mutualisée dans une grande organisation — un flow malveillant d'un projet peut potentiellement accéder aux données d'autres projets si l'isolation n'est pas rigoureusement implémentée au niveau de l'infrastructure, pas seulement au niveau applicatif.

Langflow, cobaye malgré lui : trois CVE critiques en six mois

Langflow n'est pas une solution mal construite par une équipe incompétente. C'est un produit open source sérieux, avec une communauté active, adopté et soutenu par DataStax qui a investi des ressources réelles dans son développement. Mais la vélocité du développement, la pression du marché, et la philosophie initiale de facilité d'usage ont laissé passer des failles architecturales fondamentales qui ont ensuite été découvertes — et dans certains cas exploitées — par des chercheurs et des attaquants.

CVE-2026-33017 (CVSS entre 9.3 et 9.8 selon les évaluateurs) a été divulguée le 17 mars 2026. L'exploitation active a été observée dans les 20 heures suivant la publication de l'advisory par les équipes de Sonicwall qui ont documenté les premières tentatives d'exploitation en production réelle. Ce délai de 20 heures illustre parfaitement la dynamique actuelle du threat intelligence : les attaquants s'organisent collectivement pour exploiter rapidement les vulnérabilités critiques dans des outils populaires, souvent avant que les équipes défensives aient eu le temps de lire l'advisory, d'évaluer leur exposition, d'identifier leurs instances vulnérables et de planifier un patch.

CVE-2025-34291 (CVSS 9.4), une erreur de validation d'origine permettant des requêtes cross-origin malveillantes portant les credentials de la victime, a été ajoutée au catalogue CISA KEV le 21 mai 2026. Cette inscription officialise l'exploitation active et impose une remédiation fédérale avant le 4 juin 2026. La faille concerne toutes les versions de Langflow antérieures à 1.8.x, soit la très grande majorité des instances self-hosted en production.

CVE-2026-33309 (CVSS 10.0) représente le cas le plus grave : le score maximal signifie que la vulnérabilité est trivialement exploitable depuis Internet, sans authentification préalable, et aboutit à une compromission totale du système cible. Un CVSS 10.0 sur un outil installé dans des milliers de SI d'entreprise dans le monde est un événement de sécurité majeur.

Ces trois CVE en six mois sur un seul outil ne sont pas une coïncidence. Elles reflètent une réalité bien documentée dans l'histoire de la sécurité logicielle : quand un outil populaire attire l'attention des chercheurs en sécurité, les vulnérabilités cachées par l'obscurité relative du produit remontent rapidement à la surface. D'autres outils d'orchestration IA — Flowise, Dify, n8n — n'ont peut-être pas encore fait l'objet du même niveau de scrutin. Cela ne signifie pas qu'ils sont plus sûrs. Cela signifie seulement que leurs vulnérabilités n'ont pas encore été découvertes. La question n'est pas si, mais quand.

Ce que j'observe sur le terrain

Dans les missions d'audit que je conduis, j'ai commencé à intégrer systématiquement un volet "inventaire des outils IA" depuis début 2025. Ce que j'y trouve est révélateur et, souvent, préoccupant.

Premier constat : les RSSI ne savent pas que Langflow est déployé dans leur SI. Dans la moitié des organisations auditées où j'ai trouvé une instance d'orchestration IA, le RSSI n'était pas au courant de son existence. L'outil avait été installé par un data scientist ou une équipe produit sans notification à la sécurité. Dans le meilleur des cas, une demande d'ouverture de port avait été soumise à l'équipe réseau sans que la nature du service soit précisée. Dans le pire des cas, l'instance tournait sur un serveur déjà dans la DMZ pour d'autres raisons, exploitant une règle firewall existante.

Deuxième constat : les clés API LLM ne sont pas protégées. Dans 100 % des déploiements Langflow que j'ai audités, les clés API OpenAI, Anthropic ou Google étaient stockées en clair dans la configuration des flows ou dans des variables d'environnement lisibles par n'importe quel processus tournant sur la même machine. Certaines clés avaient des quotas d'utilisation mensuels de plusieurs centaines d'euros. Une clé API LLM compromise ne représente pas seulement un risque de confidentialité — c'est un risque financier direct et une porte d'entrée vers des données traitées par les LLM.

Troisième constat : le log des échanges LLM est inexistant. Dans un contexte de conformité RGPD, NIS2 et DORA, le log des échanges avec les API LLM n'est pas optionnel — c'est une pratique de sécurité à part entière. Sans logs, impossible de savoir quelles données ont été transmises à OpenAI (hébergé aux États-Unis, hors souveraineté européenne), de détecter une injection de prompt malveillante, ou de répondre à une demande d'audit réglementaire. L'aveuglement est total.

Quatrième constat : les mises à jour ne sont pas appliquées. Les équipes qui déploient ces outils en mode "PoC devenu production" ne maintiennent pas de processus de mise à jour rigoureux. Une instance Langflow installée en janvier 2026 peut tourner sans aucun patch six mois plus tard, exposée à l'ensemble des CVE publiées dans l'intervalle. C'est exactement la situation que CVE-2026-33017, CVE-2025-34291 et CVE-2026-33309 exploitent.

La gouvernance des outils IA : le nouveau défi du RSSI

La sécurisation des pipelines IA no-code ne se résume pas à appliquer des patches quand ils arrivent. Elle nécessite une approche de gouvernance structurée que la plupart des organisations n'ont pas encore mise en place. Voici les axes fondamentaux que je recommande à mes clients.

L'inventaire exhaustif. Vous ne pouvez pas sécuriser ce que vous ne connaissez pas. Le premier travail est de cartographier tous les déploiements d'outils d'orchestration IA dans le SI. Cela passe par une analyse des flux réseau sortants (connexions vers les API OpenAI, Anthropic, Google, Pinecone, Weaviate), une revue des demandes d'ouverture de ports des 24 derniers mois, et une intégration dans la CMDB. Des outils de type CAASM (Cyber Asset Attack Surface Management) peuvent automatiser une partie de cette découverte. En pratique, dans les organisations de taille intermédiaire, un scan réseau interne à la recherche des ports caractéristiques de ces plateformes (7860 pour Langflow, 3000 pour Flowise, 5678 pour n8n) suffit à révéler une grande partie de l'exposition.

La classification des flows. Tous les pipelines IA ne présentent pas le même niveau de risque. Un flow qui génère des résumés d'articles publics est différent d'un flow qui accède à une base documentaire RH ou à des données financières clients. Chaque flow doit être classifié selon la sensibilité des données traitées et les systèmes auxquels il se connecte. Cette classification détermine les contrôles requis : chiffrement au repos des configurations, audit logging des appels, restrictions réseau strictes, revue de code des nodes personnalisés, et évaluation DPIA sous RGPD.

Le principe du moindre privilège. Les instances d'orchestration IA doivent s'exécuter avec les droits minimaux nécessaires. En pratique : utilisateur système dédié sans privilège root, accès réseau sortant restreint aux seules API externes nécessaires via whitelist dans le firewall, secrets stockés dans un coffre-fort (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) et non dans les variables d'environnement ou la configuration des flows, et network namespace dédié en environnement Kubernetes.

Le monitoring des appels LLM. Logguer les appels sortants vers les API LLM est une pratique de sécurité à part entière, pas seulement un outil de contrôle des coûts. Cela permet de détecter des exfiltrations de données via des prompts malveillants, des usages anormaux (volumes inhabituels, appels vers des modèles non autorisés, horaires suspects), et de répondre à des exigences d'audit réglementaire. Des solutions comme LangSmith (LangChain), Langfuse, ou des proxies d'API avec logging peuvent remplir ce rôle selon le contexte.

L'intégration dans le cycle de vie des correctifs. Les outils d'orchestration IA doivent figurer dans le processus de gestion des vulnérabilités de l'organisation, avec des SLA de remédiation alignés sur leur criticité. CVE CVSS 9.0+ dans un outil d'orchestration IA accessible depuis Internet doit déclencher le même niveau de réponse qu'une CVE équivalente dans un firewall ou un VPN. Ce n'est pas encore la norme — il faut que ça le devienne.

Conclusion : le temps de l'inventaire, de la gouvernance et de la rigueur

La question n'est plus de savoir si des pipelines IA no-code sont déployés dans votre SI — ils le sont probablement déjà, avec ou sans votre accord. La question est de savoir dans quel état ils se trouvent, qui y a accès, quelles données ils traitent, et si leurs vulnérabilités critiques ont été patchées. La bonne nouvelle : les mesures sont relativement simples à mettre en place une fois que la décision politique de les appliquer a été prise par la direction.

Un inventaire exhaustif, des règles réseau adaptées, des secrets dans un coffre-fort, un processus de mise à jour intégré dans la gestion des vulnérabilités, et un minimum de monitoring : ce n'est pas de la rocket science. C'est de l'hygiène de sécurité fondamentale appliquée à une nouvelle catégorie d'outils. Ce qui est plus complexe — et c'est là que le RSSI doit jouer son rôle — c'est d'imposer ces contraintes aux équipes qui déploient ces outils pour leur efficacité et leur rapidité, souvent en dehors des circuits de validation habituels. La sécurité ne doit pas tuer l'innovation : elle doit l'encadrer. En 2026, ignorer la surface d'attaque des outils IA no-code n'est plus une option acceptable.