CVE-2026-41270: Flowise SSRF Protection Bypass Vulnerability

CVE-2026-41270 Overview

A Server-Side Request Forgery (SSRF) protection bypass vulnerability has been identified in Flowise, a popular drag & drop user interface for building customized large language model (LLM) flows. Prior to version 3.1.0, the Custom Function feature contains a critical security flaw that allows authenticated users to circumvent SSRF controls and access internal network resources.

While Flowise implements SSRF protection via HTTP_DENY_LIST for the axios and node-fetch libraries, the built-in Node.js http, https, and net modules are permitted within the NodeVM sandbox without equivalent protection. This inconsistency enables attackers to bypass security controls and potentially access sensitive internal resources such as cloud provider metadata services.

Critical Impact

Authenticated attackers can bypass SSRF protections to access internal network resources, including cloud provider metadata services, potentially exposing sensitive credentials and configuration data.

Affected Products

• Flowise versions prior to 3.1.0
• Flowise Custom Function feature with NodeVM sandbox
• Self-hosted Flowise instances on cloud infrastructure

Discovery Timeline

• April 23, 2026 - CVE-2026-41270 published to NVD
• April 23, 2026 - Last updated in NVD database

Technical Details for CVE-2026-41270

Vulnerability Analysis

This vulnerability represents a classic case of incomplete security controls, classified under CWE-284 (Improper Access Control). The Flowise application attempts to implement SSRF protection by maintaining an HTTP_DENY_LIST that restricts requests made through the axios and node-fetch libraries. However, the security boundary is incomplete because the NodeVM sandbox environment permits direct access to Node.js built-in modules (http, https, and net) without applying equivalent filtering rules.

The attack requires authenticated access to the Flowise platform and the ability to create or modify Custom Functions. Once an attacker gains this access, they can craft JavaScript code within the Custom Function that utilizes the native Node.js networking modules to initiate requests to internal network addresses that would otherwise be blocked.

Root Cause

The fundamental issue stems from an inconsistent security policy implementation. The developers correctly identified the need to restrict outbound network requests but only applied protections to third-party HTTP libraries while overlooking the built-in Node.js networking capabilities. The NodeVM sandbox, designed to provide isolation, still exposes these core modules, creating a gap in the security perimeter.

This architectural oversight allows code running within the sandbox to bypass the application-level SSRF protections entirely by simply using require('http') or require('https') instead of the protected libraries.

Attack Vector

The attack is network-based and requires low-privilege authenticated access to the Flowise application. An attacker with the ability to create Custom Functions can exploit this vulnerability by writing JavaScript code that:

1. Imports the native http, https, or net modules within the Custom Function
2. Constructs requests targeting internal network resources (e.g., 169.254.169.254 for AWS metadata)
3. Exfiltrates sensitive information such as cloud credentials, internal service responses, or infrastructure details

The vulnerability is particularly dangerous in cloud environments where metadata services can expose IAM credentials, allowing lateral movement and privilege escalation within the cloud infrastructure.

For detailed technical information about this vulnerability, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-41270

Indicators of Compromise

• Custom Function code containing imports of http, https, or net modules
• Outbound network connections to internal IP ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• Requests to cloud metadata endpoints such as 169.254.169.254 from the Flowise application
• Unusual network traffic patterns originating from Flowise server processes

Detection Strategies

• Monitor Custom Function code submissions for usage of built-in Node.js networking modules
• Implement network-level monitoring to detect SSRF attempts targeting internal resources
• Review Flowise application logs for suspicious Custom Function executions
• Deploy endpoint detection tools to identify unexpected outbound connections from application containers

Monitoring Recommendations

• Enable verbose logging for Custom Function execution within Flowise
• Configure network segmentation alerts for traffic between application tier and metadata services
• Implement real-time alerting for connections to known internal service endpoints
• Audit Custom Function code during code review processes

How to Mitigate CVE-2026-41270

Immediate Actions Required

• Upgrade Flowise to version 3.1.0 or later immediately
• Review existing Custom Functions for potentially malicious code utilizing native Node.js modules
• Restrict Custom Function creation permissions to trusted administrators only
• Implement network-level SSRF protection using firewall rules to block access to internal resources

Patch Information

This vulnerability has been fixed in Flowise version 3.1.0. The patch addresses the inconsistency by extending SSRF protection to cover the built-in Node.js networking modules within the NodeVM sandbox. Organizations should update to the patched version as the primary remediation strategy.

For more details about the security fix, consult the GitHub Security Advisory.

Workarounds

• Block access to cloud metadata services at the network level using firewall rules or security groups
• Disable the Custom Function feature if not required for business operations
• Implement additional network segmentation to isolate Flowise instances from sensitive internal resources
• Use Web Application Firewall (WAF) rules to detect and block SSRF attempts

# Example: Block metadata service access via iptables (Linux)
iptables -A OUTPUT -d 169.254.169.254 -j DROP
iptables -A OUTPUT -d 169.254.0.0/16 -j DROP

# Example: Restrict internal network access from application containers
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