CVE-2026-67620 - SSRF de Flowise via une liste de blocage incomplète des métadonnées cloud (Oracle OCI 192.0.0.192 + Alibaba 100.100.100.200 contournent la DEFAULT_DENY_LIST)
Produit : FlowiseAI/Flowise — constructeur visuel de LLM / d'agents IA (~54k ★)
Versions affectées : ≤ 3.1.4 — vulnérabilité confirmée dans 3.1.4, la dernière version (revérifié le 2026-08-06)
Vulnérabilité : Falsification de requête côté serveur (SSRF) via une liste de refus incomplète
CWE : CWE-918 (SSRF) · CWE-184 (Liste incomplète des entrées interdites)
Gravité : Moyenne — CVSS 3.1 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Découverte : 2026-07-10 · Signalée à VulnCheck (CVD) : 2026-07-15
Chercheur : Bobur Abdugafforov (Mahadsec)
Statut du fournisseur — aucun correctif ne sera publié. Le projet Flowise a été officiellement abandonné et n'accepte plus de signalements de vulnérabilités de sécurité. Cet avis est publié afin que les opérateurs qui utilisent encore Flowise puissent atténuer le problème eux-mêmes.
Flowise embarque une protection SSRF qui bloque les requêtes vers les services de métadonnées d'instances cloud. La
liste de refus couvre la plage link-local 169.254.0.0/16 utilisée par AWS, GCP, Azure et
DigitalOcean — mais omet deux adresses de métadonnées qui ne se trouvent pas dans cette plage :
| Cloud | IP de métadonnées | Dans la liste de refus ? |
|---|---|---|
| AWS / GCP / Azure / DigitalOcean | 169.254.169.254 | ✅ bloquée |
| Oracle Cloud (OCI) | 192.0.0.192 | ❌ non bloquée |
| Alibaba Cloud | 100.100.100.200 | ❌ non bloquée |
La DEFAULT_DENY_LIST complète fournie dans l'image Docker officielle flowiseai/flowise:3.1.4
(.../flowise-components/dist/src/httpSecurity.js) est :
'0.0.0.0', '10.0.0.0/8', '127.0.0.0/8', '169.254.0.0/16', '169.254.169.253',
'169.254.169.254', '172.16.0.0/12', '192.168.0.0/16', '224.0.0.0/4', '240.0.0.0/4',
'255.255.255.255/32', '::1', 'fc00::/7', 'fd00:ec2::254', 'fe80::/10', 'ff00::/8',
'localhost', 'ip6-localhost'
18 entrées. Ni 192.0.0.192 ni 100.100.100.200 n'apparaissent, et aucune des deux ne tombe
à l'intérieur d'un CIDR listé — notez que 192.168.0.0/16 ne couvre pas 192.0.0.192, et
il n'y a aucune entrée 100.64.0.0/10 (CGNAT) du tout.
La liste est identique octet pour octet entre 3.1.2 et 3.1.4. Le seul changement apporté à
httpSecurity.ts au fil de ces versions est la normalisation des IPv6 mappées en IPv4 à l'intérieur de
isDeniedIP(), ce qui ne peut pas affecter deux adresses IPv4 simples.
Aucune des adresses omises ne tombe à l'intérieur d'un CIDR privé ou link-local conventionnel :
192.0.0.192 se trouve dans le bloc IETF Protocol Assignments 192.0.0.0/24 et semble
routable globalement, tandis que 100.100.100.200 se situe dans la plage CGNAT 100.64.0.0/10, que
la deny-list ne couvre pas non plus. Une protection construite en énumérant « l'IP de métadonnées » et la
plage link-local manque donc les deux.
Un utilisateur authentifié peut forcer le serveur Flowise à émettre des requêtes GET arbitraires vers ces adresses. Sur un déploiement OCI ou Alibaba Cloud, cela atteint le service de métadonnées de l'instance, qui fournit l'identité de l'instance et le matériel d'identification.
packages/components/src/httpSecurity.ts — DEFAULT_DENY_LIST
(compilé : httpSecurity.js:31-50)
La liste contient 169.254.169.254 et la plage 169.254.0.0/16, mais ne contient pas
192.0.0.192, 100.100.100.200, ni la plage CGNAT 100.64.0.0/10.
Flux de la requête : GET /api/v1/fetch-links → checkDenyList(url) → secureFetch() via
webCrawl. secureFetch revalide correctement les cibles de redirection, donc les contournements
basés sur les redirections sont gérés — le défaut réside dans le contenu de la liste, ce qui signifie qu'une redirection
vers l'une ou l'autre des IP omises passe la validation tout comme une requête directe.
La route fetch-links ne porte aucun middleware checkPermission, donc toute session authentifiée
y accède quel que soit le rôle.
GET /api/v1/fetch-links?url=<target>&relativeLinksMethod=webCrawl&limit=1
Chaque nœud effectuant un routage via secureFetch / secureAxiosRequest avec une URL fournie par l'utilisateur
est affecté par la même liste de refus — par exemple les nœuds web-scraper et HTTP-request.
Note sur l'accessibilité : le problème est en outre accessible sans authentification via
le point de terminaison public POST /api/v1/prediction/:id dès lors qu'un nœud de récupération d'URL est présent
dans un chatflow rendu public.
Confirmé dynamiquement sur une instance Flowise 3.1.2 locale active, avec des écouteurs liés à
192.0.0.192:80 et 100.100.100.200:80.
Contrôle — l'IP des métadonnées AWS/GCP/Azure est correctement bloquée :
GET /api/v1/fetch-links?url=http://169.254.169.254/latest/meta-data/&relativeLinksMethod=webCrawl&limit=1
HTTP/1.1 500
isDeniedIP: Error: Access to this host is denied by policy.
Contournement 1 — Métadonnées Oracle Cloud :
GET /api/v1/fetch-links?url=http://192.0.0.192/opc/v1/instance/&relativeLinksMethod=webCrawl&limit=1
HTTP/1.1 200
{"status":"OK","links":["http://192.0.0.192/opc/v1/instance"]}
Contournement 2 — Métadonnées d'Alibaba Cloud :
GET /api/v1/fetch-links?url=http://100.100.100.200/&relativeLinksMethod=webCrawl&limit=1
HTTP/1.1 200
Requêtes côté serveur observées sur les écouteurs (prouvant que la récupération provenait du serveur Flowise, et non du client) :
# OCI listener
192.0.0.192 - - [11/Jul/2026 04:34:35] "GET /opc/v1/instance/ HTTP/1.1" 404 -
192.0.0.192 - - [11/Jul/2026 04:34:54] "GET /opc/v1/instance HTTP/1.1" 404 -
# Alibaba listener
100.100.100.200 - - [11/Jul/2026 04:34:35] "GET / HTTP/1.1" 200 -
100.100.100.200 - - [11/Jul/2026 04:34:54] "GET / HTTP/1.1" 200 -
Un script PoC est inclus sous poc.py.
Tout utilisateur authentifié de Flowise — et, lorsqu'un nœud de récupération d'URL se trouve dans un chatflow public, tout visiteur non authentifié — peut amener le serveur à émettre des requêtes GET vers les services de métadonnées d'instance d'Oracle Cloud et d'Alibaba Cloud, ce que le produit tente explicitement d'empêcher pour d'autres fournisseurs.
Sur un déploiement affecté, cela expose les données d'identité de l'instance et les points de terminaison de métadonnées qui fournissent les identifiants de rôle d'instance, à partir desquels s'ensuit un accès supplémentaire au compte cloud de la victime. Plus largement, la même lacune permet des requêtes vers la plage CGNAT 100.64.0.0/10, qui est routable à l'intérieur de nombreux réseaux de fournisseurs.
La gravité reflète le fait que l'exploitation nécessite que l'instance Flowise soit hébergée sur OCI ou Alibaba Cloud. Le défaut lui-même — une liste de refus incomplète — est indépendant du fournisseur.
Aucun correctif du fournisseur ne sera publié ; le projet est abandonné. Les opérateurs doivent :