CVE-2026-69257 in Flowise
Summary
by MITRE • 08/04/2026
Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, Flowise's HTTP security module httpSecurity.ts did not normalize IPv4-mapped IPv6 addresses such as ::ffff:127.0.0.1 and ::ffff:169.254.169.254 before checking them against the deny list. Because ipaddr.js reports these addresses as ipv6 while IPv4 CIDR deny-list entries are ipv4, isDeniedIP() skipped the IPv4 CIDR checks. An attacker who controls DNS resolution for a hostname used by the HTTP Node, API Chain, Document Loader, MCP tool, or other paths using secureAxiosRequest(), secureFetch(), or checkDenyList() could return a AAAA record for an IPv4-mapped target and cause requests to reach localhost, internal services, or cloud metadata endpoints. This issue is fixed in version 3.1.3.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/04/2026
The vulnerability in Flowise versions prior to 3.1.3 represents a critical security flaw in the HTTP security module that stems from improper handling of IPv4-mapped IPv6 addresses. This weakness exists within the httpSecurity.ts file where the isDeniedIP() function fails to normalize IPv4-mapped IPv6 addresses such as ::ffff:127.0.0.1 and ::ffff:169.254.169.254 before performing access control checks against deny lists. The root cause lies in how the ipaddr.js library processes these addresses, reporting them as IPv6 type while the deny list entries are configured for IPv4 CIDR ranges. This fundamental mismatch causes the security validation logic to bypass IPv4 CIDR checks entirely when encountering IPv4-mapped addresses, creating a dangerous bypass mechanism that undermines network isolation controls.
The operational impact of this vulnerability is severe and directly enables attackers to circumvent local network access controls through DNS-based attacks. When an attacker controls DNS resolution for hostnames used by Flowise's HTTP Node, API Chain, Document Loader, MCP tool, or other components that rely on secureAxiosRequest(), secureFetch(), or checkDenyList() functions, they can manipulate DNS responses to return AAAA records pointing to IPv4-mapped addresses. This manipulation allows attackers to redirect network requests to localhost services, internal network endpoints, or cloud metadata servers that should remain inaccessible to external or untrusted networks. The vulnerability essentially transforms a security boundary designed to prevent local network access into a tunnel for unauthorized access to sensitive internal resources.
This issue directly maps to CWE-284 (Improper Access Control) and CWE-310 (Cryptographic Issues) within the Common Weakness Enumeration framework, representing a failure in proper input validation and access control enforcement. From an attacker's perspective, this vulnerability aligns with ATT&CK techniques such as T1071.004 (Application Layer Protocol: DNS) for DNS manipulation and T1566.001 (Phishing: Spearphishing Attachment) for initial compromise through DNS control. The flaw demonstrates a classic case of insufficient address normalization in network security controls, where the security model assumes consistent address types while the implementation fails to account for IPv4-mapped IPv6 representations that are commonly encountered in modern network environments.
The fix implemented in Flowise version 3.1.3 addresses this vulnerability by ensuring proper normalization of IPv4-mapped IPv6 addresses before access control decisions are made. This normalization process converts IPv4-mapped addresses to their standard IPv4 representation, allowing the deny list checks to function correctly regardless of how the addresses are presented. Organizations should immediately upgrade to version 3.1.3 or later to remediate this vulnerability, while also implementing additional monitoring for suspicious DNS resolution patterns and network access attempts that might indicate exploitation attempts. Security teams should review their own network security policies to ensure similar normalization issues do not exist in other components that handle mixed IPv4/IPv6 address representations, particularly in systems that perform access control decisions based on IP address ranges.