Flowise SSRF via Incomplete Cloud Metadata Deny-List

Overview

Flowise, the popular open-source low-code LLM orchestration framework, contains a server-side request forgery (SSRF) vulnerability in versions through 3.1.4. The root cause is an incomplete DEFAULT_DENY_LIST in httpSecurity.ts, which enforces URL restrictions for outbound HTTP requests. While the implementation correctly blocks well-known cloud metadata endpoints such as the AWS link-local address (169.254.169.254) and the Google Cloud metadata FQDN, it omits two critical targets: Oracle Cloud Infrastructure’s metadata endpoint at 192.0.0.192 and Alibaba Cloud’s metadata endpoint at 100.100.100.200. An authenticated attacker — or in certain chatflow configurations, an unauthenticated one — can exploit the fetch-links API endpoint to force the Flowise server to retrieve arbitrary URLs, including these unguarded metadata services.

The vulnerability is particularly relevant in enterprise and cloud-native deployments where Flowise instances run on OCI or Alibaba Cloud compute resources with attached IAM roles or instance profiles. Successful exploitation yields instance identity documents and short-lived role credentials, which can be leveraged for lateral movement across the cloud environment. The CVSS score of 7.7 (HIGH) reflects the high impact on confidentiality and the relatively low attack complexity once an attacker has access to the API, with the score tempered only by the network-adjacent attack vector in typical authenticated configurations.

Security researchers identified this gap through analysis of the SSRF guard implementation and cross-referencing the deny-list against the full matrix of cloud provider metadata endpoints. Flowise has since announced a product sunset, which means no upstream patch is forthcoming; operators must implement mitigations at the infrastructure level.

Technical Analysis

The SSRF guard in Flowise is implemented in packages/server/src/httpSecurity.ts. The intent is to prevent Flowise nodes — particularly those that fetch external content, such as the fetch-links document loader — from making requests to private or privileged network ranges. The guard is invoked before every outbound HTTP request and checks the resolved destination against a hard-coded deny-list.

The vulnerable deny-list looks approximately as follows:

// httpSecurity.ts (vulnerable — Flowise <= 3.1.4)
const DEFAULT_DENY_LIST: string[] = [
  '169.254.169.254',       // AWS / generic link-local
  'metadata.google.internal', // GCP metadata FQDN
  'fd00:ec2::254',         // AWS IPv6 metadata
  '::1',                   // IPv6 loopback
  'localhost',
  '127.0.0.1',
  '0.0.0.0',
  '10.0.0.0/8',
  '172.16.0.0/12',
  '192.168.0.0/16',
]

export function isURLDenied(resolvedHostname: string): boolean {
  return DEFAULT_DENY_LIST.some((entry) => {
    if (entry.includes('/')) {
      return ipRangeCheck(resolvedHostname, entry)
    }
    return resolvedHostname === entry || resolvedHostname.endsWith(`.${entry}`)
  })
}

Two metadata endpoints are conspicuously absent:

• Oracle Cloud Infrastructure: 192.0.0.192 — OCI’s Instance Metadata Service (IMDS) responds on this non-RFC-1918 address, which means it falls outside the private range blocks (10/8, 172.16/12, 192.168/16) already in the list.
• Alibaba Cloud: 100.100.100.200 — Alibaba’s metadata endpoint lives in the 100.64.0.0/10 shared address space (RFC 6598, carrier-grade NAT), which is also absent from the deny-list.

An attacker crafts a POST request to the /api/v1/fetch-links endpoint with a url parameter pointing to one of these addresses. The guard evaluates the hostname, finds no match in DEFAULT_DENY_LIST, and allows the request to proceed. The Flowise server then issues the GET request from its own network interface — which has direct Layer 3 access to the metadata service — and returns the response body to the caller.

Additionally, the implementation resolves hostnames before checking against the list, but does not re-validate after HTTP redirects. A redirect chain from a permitted domain to 100.100.100.200 would bypass the guard entirely, compounding the attack surface.

A minimal proof-of-concept request:

POST /api/v1/fetch-links HTTP/1.1
Host: flowise.example.com
Authorization: Bearer <token>
Content-Type: application/json

{
  "url": "http://100.100.100.200/latest/meta-data/ram/security-credentials/",
  "chatflowid": "<chatflow-uuid>"
}

The server responds with the list of attached RAM roles, and a follow-up request to http://100.100.100.200/latest/meta-data/ram/security-credentials/<role-name> yields a JSON document containing AccessKeyId, AccessKeySecret, and SecurityToken.

Impact

On Oracle Cloud Infrastructure deployments, a successful request to http://192.0.0.192/opc/v2/instance/ returns the full instance identity document, including tenancy OCID, compartment OCID, region, and shape. Requests to http://192.0.0.192/opc/v2/identity/ expose the dynamic group memberships and associated IAM policy bindings. If the compute instance carries an instance principal with broad permissions, the attacker can use the obtained credentials to enumerate or modify OCI resources.

On Alibaba Cloud, the RAM security credentials endpoint yields temporary STS tokens valid for up to six hours. Depending on the role’s permission boundary, this can enable full control over attached ECS instances, OSS buckets, RDS databases, and other Alibaba Cloud services within the account.

The severity is elevated in configurations where Flowise chatflows are exposed publicly without authentication — a supported and documented deployment pattern for customer-facing chatbots. In such cases, the attack requires no credentials whatsoever, and the effective attack vector shifts from network to internet-accessible.

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N reflects the scope change inherent in metadata credential theft: the confidentiality impact extends beyond the Flowise application itself to the broader cloud account.

How to Fix It

Since Flowise has announced end-of-life, no official patch will be released. Operators should apply the following mitigations in order of effectiveness.

1. Block metadata endpoints at the network layer.

On OCI, use Security Lists or Network Security Groups to deny egress from the Flowise compute instance to 192.0.0.192/32. On Alibaba Cloud, use Security Group egress rules to deny 100.100.100.200/32. This is the most reliable control because it is independent of application logic.

2. If self-hosting a fork, patch httpSecurity.ts directly.

// httpSecurity.ts (patched)
const DEFAULT_DENY_LIST: string[] = [
  '169.254.169.254',
  'metadata.google.internal',
  'fd00:ec2::254',
  '::1',
  'localhost',
  '127.0.0.1',
  '0.0.0.0',
  // OCI metadata — non-RFC-1918, must be listed explicitly
  '192.0.0.192',
  // Alibaba Cloud metadata — RFC 6598 range not covered by private blocks
  '100.100.100.200',
  // Block the entire RFC 6598 carrier-grade NAT range for defense in depth
  '100.64.0.0/10',
  '10.0.0.0/8',
  '172.16.0.0/12',
  '192.168.0.0/16',
]

// Re-validate after every redirect hop
export function isURLDenied(resolvedHostname: string): boolean {
  return DEFAULT_DENY_LIST.some((entry) => {
    if (entry.includes('/')) {
      return ipRangeCheck(resolvedHostname, entry)
    }
    return resolvedHostname === entry || resolvedHostname.endsWith(`.${entry}`)
  })
}

3. Disable redirect following in outbound HTTP clients.

Configure follow: 0 (node-fetch) or equivalent to prevent redirect-based bypass chains regardless of deny-list completeness.

4. Migrate away from Flowise.

Given the sunset announcement, the authoritative remediation is migration to an actively maintained LLM orchestration platform before security patches cease entirely.

Our Take

Incomplete deny-lists are a recurring failure mode in SSRF mitigations. Developers typically author these lists by enumerating the metadata endpoints they personally know — usually AWS because it dominates cloud market share in the developer’s own experience. OCI and Alibaba Cloud endpoints are routinely overlooked, as is the RFC 6598 100.64/10 range, which hosts not only Alibaba’s metadata service but also internal services in carrier and enterprise environments.

The deeper issue is that deny-lists are fundamentally the wrong primitive for SSRF prevention. A robust implementation should combine an allowlist of permitted destination FQDNs (when the set is known), mandatory re-validation after redirects, a complete block of all RFC 1918 and RFC 6598 ranges, and DNS rebinding protection that re-resolves the hostname immediately before connection establishment. Any one of these controls alone is bypassable; defense in depth requires all of them.

For enterprises running AI-powered applications that fetch external URLs — a capability that is central to RAG pipelines and document loaders — SSRF is not an edge case. It is a predictable consequence of the architecture. Security review of any URL-fetching component must include an explicit audit of all cloud metadata endpoint families, not just the AWS canonical address.

Detection with SAST

This vulnerability class maps to CWE-918: Server-Side Request Forgery (SSRF) and the sub-weakness CWE-1327: Binding to an Unrestricted IP Address when applied to deny-list incompleteness.

Offensive360’s SAST engine detects this pattern through a combination of taint tracking and deny-list completeness analysis:

• Taint source identification: User-supplied URL parameters flowing into HTTP client calls (fetch, axios.get, node-fetch) are flagged as taint sources.
• Sanitizer gap analysis: When a deny-list check is identified as a sanitizer for SSRF, our engine cross-references the literal values in the list against a curated database of known cloud metadata endpoints. Any absent entry from that database triggers a finding at HIGH severity.
• Redirect-follow detection: Calls to HTTP clients with redirect: 'follow' (the default) that are not wrapped in post-redirect host re-validation are flagged as SSRF amplifiers.
• Rule category: SSRF.INCOMPLETE_DENYLIST — distinct from a generic SSRF finding because the guard exists but is demonstrably incomplete, a nuance that matters for triage prioritization.

This type of finding is difficult for generic regex-based scanners to surface because the deny-list itself is present and looks correct at a glance. Semantic analysis that understands what the list is supposed to represent — and what is missing from it — is required to catch it reliably.

References

• [Flowise Sunset Announcement](