CVE-2026-31829: Server-Side Request Forgery in Flowise HTTP Node

Flowise is a drag-and-drop user interface designed for building customized large language model (LLM) workflows. The core functionality relies on various nodes that connect APIs, local models, and external services to facilitate complex data processing pipelines. Within these workflows, the AgentFlow and Chatflow components utilize an HTTP Node to perform server-side requests to external endpoints.

CVE-2026-31829 identifies a Server-Side Request Forgery (SSRF) vulnerability within this HTTP Node implementation. In versions prior to 3.0.13, the application fails to validate or restrict the target URLs supplied to the node. This architectural flaw permits users to specify arbitrary destinations, which the backend server will dutifully query without considering the network boundaries or security context of the target.

The resulting impact is substantial, as it transforms the Flowise server into an unauthenticated proxy for malicious actors. Attackers can leverage this capability to bypass external firewalls, interact with loopback interfaces, and access sensitive internal services that are otherwise protected from internet-facing traffic.

The root cause of CVE-2026-31829 lies in the absence of input sanitization and destination validation within the HTTP Node's execution logic. When a workflow is triggered, the node extracts the user-defined URL from its configuration properties and passes it directly to the underlying HTTP client library. The application does not perform preliminary checks against the resolved IP address or the hostname structure.

In a secure implementation, an application performing outbound web requests must perform DNS resolution on the target hostname and compare the resulting IP address against a strict allowlist or blocklist. Flowise versions prior to 3.0.13 omit this critical validation phase. Consequently, the application initiates TCP connections regardless of whether the resolved IP address resides in a restricted network space, such as an RFC 1918 private subnet or a loopback address.

Furthermore, the application lacks protections against DNS rebinding attacks or redirects to internal services. The HTTP client blindly follows the protocol instructions provided by the user input, allowing access to administrative panels, local databases, or cloud provider metadata endpoints that rely solely on network-level segmentation for security.

Exploitation of CVE-2026-31829 requires the attacker to possess the ability to create or modify a flow within the Flowise environment. This prerequisite is met if the attacker has authenticated access to the management interface or if a specific chatflow is publicly exposed and permits user-driven modifications. The required privileges are classified as low, as any user capable of interacting with the flow designer can orchestrate the attack.

The attack methodology begins with the construction of a malicious workflow. The attacker inserts an HTTP Node and configures the target URL parameter to point to a restricted internal endpoint. High-value targets typically include http://169.254.169.254/latest/meta-data/ for AWS EC2 instance metadata, http://localhost:11434 for local Ollama instances, or standard private IP ranges such as 10.0.0.0/8.

Upon executing the flow, the Flowise backend processes the node and issues the HTTP GET or POST request to the specified internal address. The server captures the HTTP response from the targeted internal resource and returns it to the attacker through the flow's standard output mechanism. This allows the attacker to read the contents of the response, completing the data exfiltration cycle.

The primary consequence of this SSRF vulnerability is the complete circumvention of network perimeter defenses. By forcing the Flowise application to act as a proxy, attackers gain the ability to interact with the internal network environment from the perspective of the compromised server. This invalidates firewall rules and Access Control Lists (ACLs) designed to protect internal assets from external interaction.

The highest severity risk involves the compromise of cloud infrastructure via the instance metadata service (IMDS). If the Flowise application is hosted on an AWS EC2 instance or an equivalent cloud compute environment, querying 169.254.169.254 permits the exfiltration of temporary Identity and Access Management (IAM) credentials. These credentials facilitate lateral movement into the broader cloud account, potentially leading to widespread data breaches or infrastructure takeover.

Additionally, the vulnerability supports systematic internal network reconnaissance. Attackers can automate requests across private IP ranges to perform port scanning and service enumeration. This activity identifies secondary targets, such as unauthenticated internal administrative interfaces, databases, or microservices, paving the way for further exploitation and deeper network compromise.

The vulnerability is officially remediated in Flowise version 3.0.13. The maintainers addressed the flaw by introducing a comprehensive host restriction policy within the HTTP Node's execution path. This patch intercepts outbound requests and validates the target destination prior to initiating the network connection.

The technical fix implements a default blocklist that denies access to common internal and private network addresses, including loopback interfaces and RFC 1918 IP spaces. To provide operational flexibility, the patch also introduces a new environment variable named HTTP_DENY_LIST. This variable allows systems administrators to define custom blocklists, enabling the restriction of specific hostnames or IP subnets tailored to their unique deployment environment.

When the patched application detects an attempt to query a restricted address, it gracefully aborts the connection and returns a standardized error message: "Error: Access to this host is denied by policy." Organizations utilizing Flowise must upgrade to version 3.0.13 immediately. Administrators should subsequently review their integrations, as the default deny policy may disrupt legitimate workflows that rely on accessing local services, as documented in user reports following the patch release.