CVE-2026-56275: Flowise SSRF Vulnerability

CVE-2026-56275 Overview

CVE-2026-56275 is a Server-Side Request Forgery (SSRF) vulnerability in Flowise versions before 3.1.0. The flaw resides in the Execute Flow node, where the base URL field accepts intranet addresses without proper validation. The vulnerability is tracked under CWE-918 and stems from a missing secureFetch verification in httpSecurity.ts. Attackers with low-privileged access can coerce the Flowise server into issuing HTTP requests against internal network endpoints, cloud instance metadata services, and otherwise unreachable backend systems.

Critical Impact
Authenticated attackers can pivot through Flowise to enumerate internal services and exfiltrate cloud metadata credentials, including IAM tokens from instance metadata endpoints.

Affected Products

Flowise versions prior to 3.1.0
Flowise Execute Flow node component
Deployments exposing the httpSecurity.ts validation path

Discovery Timeline

2026-06-23 - CVE-2026-56275 published to NVD
2026-06-23 - Last updated in NVD database

Technical Details for CVE-2026-56275

Vulnerability Analysis

Flowise is an open-source low-code platform for building large language model (LLM) workflows. The Execute Flow node allows one flow to invoke another over HTTP using a configurable base URL. Before version 3.1.0, the base URL parameter is forwarded to the HTTP client without invoking the secureFetch helper, which normally enforces address-space restrictions.

Because the request originates from the Flowise server, attackers can reach hosts that are not exposed to the public internet. This includes container orchestration APIs, internal admin panels, and the cloud provider metadata service at 169.254.169.254. Retrieved data is reflected through the Execute Flow node response, enabling enumeration and credential theft.

Root Cause

The root cause is missing SSRF protection in httpSecurity.ts. The secureFetch function — designed to block private, loopback, and link-local address ranges — is not invoked along the Execute Flow code path. As a result, the URL allow-list and IP filtering logic is bypassed entirely when a user supplies a base URL.

Attack Vector

An authenticated user with permission to create or modify flows configures the Execute Flow node base URL to point at an internal target such as http://127.0.0.1:8080, http://localhost:6379, or http://169.254.169.254/latest/meta-data/. When the flow runs, Flowise issues the outbound request from the server context and returns the response body to the attacker. Repeated requests allow port scanning, service fingerprinting, and extraction of cloud IAM credentials. Refer to the GitHub Security Advisory GHSA-9hrv-gvrv-6gf2 and the VulnCheck SSRF Advisory for technical details.

Detection Methods for CVE-2026-56275

Indicators of Compromise

Outbound HTTP requests from the Flowise process to RFC1918 addresses, 127.0.0.1, or 169.254.169.254.
Execute Flow node configurations containing internal IP addresses or hostnames in the base URL field.
Unexpected access entries in cloud metadata service logs originating from the Flowise host.
Anomalous response sizes or error codes returned through Execute Flow node executions.

Detection Strategies

Audit Flowise flow definitions and database records for baseUrl values referencing private, loopback, or link-local ranges.
Inspect application and reverse-proxy logs for Execute Flow requests targeting non-public hosts.
Correlate Flowise process network telemetry against an allow-list of expected upstream LLM and tool endpoints.

Monitoring Recommendations

Enable egress logging on the Flowise host and alert on connections to internal subnets or 169.254.169.254.
Forward Flowise application logs to a centralized analytics platform and build queries for Execute Flow node usage.
Monitor IMDS access logs in AWS, Azure, and GCP for requests sourced from LLM infrastructure hosts.

How to Mitigate CVE-2026-56275

Immediate Actions Required

Upgrade Flowise to version 3.1.0 or later, which adds secureFetch validation to the Execute Flow node.
Restrict Flowise console access to trusted administrators and remove unused low-privilege accounts.
Place the Flowise server behind an egress proxy that blocks RFC1918, loopback, and link-local destinations.
Enforce IMDSv2 with hop-limit 1 on cloud instances to prevent metadata token theft via SSRF.

Patch Information

The vulnerability is fixed in Flowise 3.1.0. The patch reintroduces secureFetch verification on the Execute Flow base URL path in httpSecurity.ts, rejecting requests that resolve to private or reserved address ranges. Patch notes and code references are available in the GitHub Security Advisory.

Workarounds

Disable the Execute Flow node for non-administrative users until upgrade is complete.
Deploy network policies or security groups that prevent the Flowise host from reaching internal services and the metadata endpoint.
Run Flowise in an isolated network segment with explicit egress rules to required LLM provider domains only.
Apply a reverse proxy or web application firewall (WAF) rule that strips or rejects requests containing private IP literals in flow configuration payloads.

bash

# Example egress restriction using iptables to block metadata and RFC1918 from the Flowise host
iptables -A OUTPUT -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -d 127.0.0.0/8 -j REJECT