CVE-2026-31829: Flowiseai Flowise SSRF Vulnerability

CVE-2026-31829 Overview

CVE-2026-31829 is a Server-Side Request Forgery (SSRF) vulnerability discovered in Flowise, a popular drag-and-drop user interface for building customized large language model (LLM) flows. Prior to version 3.0.13, Flowise exposes an HTTP Node in AgentFlow and Chatflow that performs server-side HTTP requests using user-controlled URLs without any restrictions on target hosts.

This vulnerability allows attackers to force the Flowise server to make requests to internal network resources, including private/internal IP ranges (RFC 1918), localhost, and cloud metadata endpoints—resources that would otherwise be inaccessible from the public internet.

Critical Impact
Attackers can exploit publicly exposed Flowise chatflows to access internal network resources, potentially exposing sensitive cloud metadata, internal services, and private network infrastructure.

Affected Products

Flowise versions prior to 3.0.13
FlowiseAI Flowise (all deployments with exposed HTTP Node functionality)
Flowise instances with publicly accessible AgentFlow or Chatflow endpoints

Discovery Timeline

2026-03-10 - CVE-2026-31829 published to NVD
2026-03-11 - Last updated in NVD database

Technical Details for CVE-2026-31829

Vulnerability Analysis

The vulnerability exists in the HTTP Node component within Flowise's AgentFlow and Chatflow features. This node allows users to configure server-side HTTP requests, but the implementation lacks proper validation and restriction of target URLs. When a chatflow is publicly exposed, any user interacting with it can influence the URLs that the Flowise server will request.

The lack of URL validation is particularly dangerous in cloud environments where metadata endpoints (such as AWS's 169.254.169.254, GCP's metadata server, or Azure's IMDS) can be accessed to retrieve sensitive information including instance credentials, API keys, and configuration data.

This is a classic SSRF pattern where user input directly controls the destination of server-initiated requests without proper sanitization or allowlist enforcement.

Root Cause

The root cause is the absence of URL validation and access controls in the HTTP Node implementation. Specifically, the vulnerability stems from:

No restriction on private/internal IP ranges (RFC 1918 addresses like 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
No blocking of localhost addresses (127.0.0.1, ::1)
No protection against cloud metadata endpoint access
User-controlled URL parameters being passed directly to server-side HTTP request functions

Attack Vector

The attack is network-based and requires low privileges to execute. An attacker can interact with a publicly exposed Flowise chatflow and craft malicious requests that cause the server to:

Probe internal network services and infrastructure
Access cloud provider metadata endpoints to steal credentials
Interact with internal APIs not intended for public access
Perform port scanning of internal network resources
Bypass network segmentation and firewall rules

For example, an attacker could submit a request targeting http://169.254.169.254/latest/meta-data/iam/security-credentials/ on AWS to retrieve temporary IAM credentials, or target internal microservices running on private addresses.

The vulnerability mechanism involves the HTTP Node accepting user-supplied URLs without validation and executing server-side requests to those destinations. Technical details and the specific fix implementation can be found in the GitHub Security Advisory.

Detection Methods for CVE-2026-31829

Indicators of Compromise

Outbound HTTP requests from Flowise server to internal IP ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x)
Requests to cloud metadata endpoints (169.254.169.254)
Unusual HTTP traffic patterns from Flowise to localhost or loopback addresses
Failed connection attempts to internal services from the Flowise application

Detection Strategies

Monitor Flowise server egress traffic for connections to RFC 1918 private address space
Implement alerting on any requests to cloud provider metadata IP addresses (169.254.169.254)
Review chatflow configurations for suspicious HTTP Node URL patterns
Enable verbose logging on Flowise HTTP Node activity to capture all outbound requests

Monitoring Recommendations

Deploy network monitoring to detect internal network scanning originating from Flowise servers
Implement WAF rules to detect and block SSRF patterns in chatflow inputs
Monitor cloud provider logs for metadata API access from Flowise infrastructure
Establish baseline network behavior for Flowise instances to identify anomalous connections

How to Mitigate CVE-2026-31829

Immediate Actions Required

Upgrade Flowise to version 3.0.13 or later immediately
Review publicly exposed chatflows and restrict access where possible
Implement network-level controls to prevent Flowise from accessing internal resources
Audit existing chatflow configurations for HTTP Node usage and remove unnecessary instances

Patch Information

The vulnerability has been addressed in Flowise version 3.0.13. Organizations should upgrade to this version or later to remediate the SSRF vulnerability. The fix implements proper URL validation and restrictions on target hosts for the HTTP Node component.

For detailed patch information and release notes, refer to the GitHub Security Advisory.

Workarounds

Restrict network egress from Flowise servers using firewall rules to block access to private IP ranges and metadata endpoints
Deploy Flowise behind a reverse proxy with URL filtering capabilities
Disable or remove HTTP Node functionality from chatflows if not required for business operations
Implement network segmentation to isolate Flowise servers from sensitive internal resources

bash

# Configuration example - Block SSRF targets at firewall level
# Block cloud metadata endpoints
iptables -A OUTPUT -d 169.254.169.254 -j DROP

# Block private IP ranges (RFC 1918)
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

# Block localhost/loopback
iptables -A OUTPUT -d 127.0.0.0/8 -j DROP