CVE-2026-67620: Flowise SSRF Vulnerability

CVE-2026-67620 Overview

CVE-2026-67620 is a Server-Side Request Forgery (SSRF) vulnerability in Flowise through version 3.1.4. The flaw resides in the SSRF guard implemented in httpSecurity.ts, where the DEFAULT_DENY_LIST omits the Oracle Cloud Infrastructure (OCI) metadata endpoint 192.0.0.192 and the Alibaba Cloud metadata endpoint 100.100.100.200. Authenticated attackers can abuse the fetch-links API endpoint with a crafted URL parameter to force the server to issue arbitrary GET requests. When URL-fetching nodes exist in public chatflows, unauthenticated exploitation becomes possible. Successful exploitation exposes instance identity data and role credentials on affected cloud deployments. The vulnerability is tracked under CWE-918.

Critical Impact
Attackers can extract cloud instance metadata and IAM role credentials from OCI and Alibaba Cloud deployments, enabling lateral movement into the cloud environment.

Affected Products

Flowise versions through 3.1.4
Flowise deployments on Oracle Cloud Infrastructure (OCI)
Flowise deployments on Alibaba Cloud

Discovery Timeline

2026-08-08 - CVE-2026-67620 published to NVD
2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-67620

Vulnerability Analysis

Flowise implements an SSRF guard in httpSecurity.ts that relies on a deny-list of internal and metadata endpoints. The DEFAULT_DENY_LIST blocks common metadata IPs such as the AWS/GCP/Azure 169.254.169.254 address but omits the OCI endpoint 192.0.0.192 and the Alibaba Cloud endpoint 100.100.100.200. Because these addresses fall outside the standard link-local range, the deny-list validation permits outbound requests to them.

The fetch-links API endpoint accepts a URL parameter and issues a server-side GET request against the target. The vulnerable guard also fails to re-validate URLs after HTTP redirects, allowing redirect-based bypasses to reach otherwise filtered addresses. On OCI, the metadata service returns instance identity documents and IAM principal credentials. Alibaba Cloud's metadata service exposes RAM role Security Token Service (STS) credentials. An attacker who retrieves these credentials can pivot into the cloud tenant with the compute instance's assigned privileges.

Root Cause

The root cause is an incomplete deny-list in the SSRF guard within httpSecurity.ts. Deny-list approaches to SSRF prevention are inherently fragile because they require enumerating every sensitive internal address across every cloud provider. The implementation missed two well-documented cloud metadata endpoints and did not enforce validation across the redirect chain.

Attack Vector

Exploitation is performed over the network against the Flowise fetch-links endpoint. An authenticated attacker submits a request with the url parameter set to http://192.0.0.192/opc/v2/identity/ for OCI or http://100.100.100.200/latest/meta-data/ for Alibaba Cloud. The server issues the GET request and returns the metadata response. Attackers can also point the URL at an attacker-controlled host that responds with an HTTP 302 redirect to the metadata endpoint, bypassing initial URL checks. If a public chatflow contains a URL-fetching node, the same primitives are reachable without authentication. A proof of concept is published in the GitHub PoC for CVE-2026-67620 and detailed in the VulnCheck Security Advisory on Flowise.

Detection Methods for CVE-2026-67620

Indicators of Compromise

Outbound HTTP requests from Flowise application servers to 192.0.0.192 or 100.100.100.200.
Access log entries on the fetch-links endpoint containing URL parameters that reference cloud metadata IPs or attacker-controlled redirect hosts.
Unexpected API calls in cloud audit logs (OCI Audit, Alibaba ActionTrail) using the instance's assigned IAM or RAM role from unfamiliar source addresses.

Detection Strategies

Inspect application access logs for requests to /api/v1/fetch-links with suspicious url query values pointing to private, link-local, or cloud metadata addresses.
Correlate egress network flows from the Flowise host with authoritative allow-lists; alert on any traffic to metadata IP ranges.
Monitor for anomalous use of the instance's cloud role credentials from IPs that do not belong to the Flowise workload.

Monitoring Recommendations

Enable verbose logging on the Flowise HTTP client and forward events to a centralized SIEM for correlation.
Configure cloud provider audit trails (OCI Audit, Alibaba ActionTrail) to capture all metadata service and STS token issuance events.
Track redirects observed by the Flowise fetch client and alert when final destinations resolve to private IP space.

How to Mitigate CVE-2026-67620

Immediate Actions Required

Disable or restrict the fetch-links endpoint until an upgrade is deployed, particularly on OCI and Alibaba Cloud instances.
Audit chatflows for URL-fetching nodes exposed via public chatflows and remove or gate them behind authentication.
Rotate any IAM or RAM role credentials that could have been retrieved from the metadata service during the exposure window.

Patch Information

Flowise has been sunset by its maintainers, as noted in the Flowise AI Sunset Announcement. No vendor patch is expected. Operators should migrate to a supported alternative or apply compensating controls at the network and platform layers.

Workarounds

Enforce Instance Metadata Service v2 (IMDSv2)-equivalent hardening where supported and require session tokens for metadata access.
Block egress from the Flowise host to 192.0.0.192, 100.100.100.200, 169.254.169.254, and all RFC1918 ranges using host or cloud firewalls.
Run Flowise inside a network namespace or sidecar proxy that filters all outbound HTTP requests through an allow-list of business-required destinations.
Require authentication on all chatflows and remove URL-fetching nodes from any publicly reachable flows.

bash

# Example egress deny rules for the Flowise host (iptables)
iptables -A OUTPUT -d 192.0.0.192 -j DROP
iptables -A OUTPUT -d 100.100.100.200 -j DROP
iptables -A OUTPUT -d 169.254.169.254 -j DROP
iptables -A OUTPUT -d 169.254.0.0/16 -j DROP
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP