AI Threat AlertFlowise's HTTP security guardrails failed to catch a classic SSRF bypass: the library used to validate destination IPs treats IPv4-mapped IPv6 addresses like ::ffff:169.254.169.254 as IPv6, so it skips the IPv4 CIDR rules meant to block requests to localhost, internal services, and cloud metadata endpoints. An attacker who controls DNS for a hostname referenced by an HTTP Node, API Chain, Document Loader, or MCP tool in a Flowise workflow can return that mapped address and turn the agent's own outbound network access into an SSRF proxy reaching your internal network or cloud IAM credentials. There's no CVSS score published yet and EPSS sits at a low 0.00246 with no public exploit or Nuclei template in circulation, so this isn't under active exploitation today, but Flowise instances routinely need broad outbound access to fetch documents and call APIs, so the blast radius is real wherever this pattern is deployed. Patch to Flowise 3.1.3, where the deny-list check normalizes addresses before comparison; until then, enforce egress restrictions at the network layer (block 169.254.169.254 and RFC1918 ranges via firewall, not just app-layer checks) and require IMDSv2 with a hop limit of 1 on cloud hosts. Given 158 other CVEs recorded against this same package, treat any Flowise deployment as a high-churn attack surface that warrants network segmentation independent of this specific fix.
What is the risk?
Moderate risk. Exploitation requires the attacker to control DNS resolution for a hostname the Flowise instance will actually request — realistic wherever a workflow lets users or external data supply a URL (chatbot-submitted links for a Document Loader, webhook/API Chain targets, MCP tool configuration). There's no authentication bypass needed beyond that; the deny-list logic itself is defeated by a documented ipaddr.js classification quirk (IPv4-mapped IPv6), making the technique reproducible once known. Impact is high where it lands: successful SSRF against a cloud metadata endpoint can yield IAM credentials and full account pivot, and internal-service SSRF can expose unauthenticated admin panels, databases, or other internal APIs. Current exploitation signals are low (no KEV listing, no public PoC, EPSS 0.00246), which lowers urgency for emergency patching but not for prioritized remediation given the severity ceiling if triggered.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Flowise | npm | <= 3.1.2 | 3.1.3 |
Do you use Flowise? You're affected.
How severe is it?
What should I do?
1 stepUpgrade to Flowise >= 3.1.3, which normalizes IPv4-mapped IPv6 addresses before deny-list comparison in httpSecurity.ts. As a compensating control (and defense in depth even post-patch), block egress to RFC1918 ranges and 169.254.169.254 at the network/firewall layer rather than relying solely on the application's deny-list, since app-layer IP filtering has now proven bypassable once already. On cloud hosts, enforce IMDSv2 with a hop limit of 1 to prevent metadata retrieval even if an SSRF request lands. Restrict which users can configure HTTP Node, API Chain, Document Loader, and MCP tool URL parameters to trusted roles. For detection, monitor outbound request logs from Flowise hosts for destinations resolving to private/link-local ranges or the metadata service, and flag DNS responses returning IPv4-mapped IPv6 addresses for externally-configured hostnames.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-69257?
Flowise's HTTP security guardrails failed to catch a classic SSRF bypass: the library used to validate destination IPs treats IPv4-mapped IPv6 addresses like ::ffff:169.254.169.254 as IPv6, so it skips the IPv4 CIDR rules meant to block requests to localhost, internal services, and cloud metadata endpoints. An attacker who controls DNS for a hostname referenced by an HTTP Node, API Chain, Document Loader, or MCP tool in a Flowise workflow can return that mapped address and turn the agent's own outbound network access into an SSRF proxy reaching your internal network or cloud IAM credentials. There's no CVSS score published yet and EPSS sits at a low 0.00246 with no public exploit or Nuclei template in circulation, so this isn't under active exploitation today, but Flowise instances routinely need broad outbound access to fetch documents and call APIs, so the blast radius is real wherever this pattern is deployed. Patch to Flowise 3.1.3, where the deny-list check normalizes addresses before comparison; until then, enforce egress restrictions at the network layer (block 169.254.169.254 and RFC1918 ranges via firewall, not just app-layer checks) and require IMDSv2 with a hop limit of 1 on cloud hosts. Given 158 other CVEs recorded against this same package, treat any Flowise deployment as a high-churn attack surface that warrants network segmentation independent of this specific fix.
Is CVE-2026-69257 actively exploited?
No confirmed active exploitation of CVE-2026-69257 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-69257?
Upgrade to Flowise >= 3.1.3, which normalizes IPv4-mapped IPv6 addresses before deny-list comparison in httpSecurity.ts. As a compensating control (and defense in depth even post-patch), block egress to RFC1918 ranges and 169.254.169.254 at the network/firewall layer rather than relying solely on the application's deny-list, since app-layer IP filtering has now proven bypassable once already. On cloud hosts, enforce IMDSv2 with a hop limit of 1 to prevent metadata retrieval even if an SSRF request lands. Restrict which users can configure HTTP Node, API Chain, Document Loader, and MCP tool URL parameters to trusted roles. For detection, monitor outbound request logs from Flowise hosts for destinations resolving to private/link-local ranges or the metadata service, and flag DNS responses returning IPv4-mapped IPv6 addresses for externally-configured hostnames.
What systems are affected by CVE-2026-69257?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, RAG pipelines, workflow automation / low-code AI builders, API orchestration (API Chain).
What is the CVSS score for CVE-2026-69257?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049Exploit Public-Facing ApplicationAML.T0053AI Agent Tool InvocationAML.T0098AI Agent Tool Credential HarvestingCompliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An attacker who can influence a URL consumed by a Flowise workflow — for example, a customer-facing chatbot that lets end users submit a link for a Document Loader node, or a malicious API Chain target — registers a domain and sets its DNS to return an AAAA record resolving to ::ffff:169.254.169.254 (or ::ffff:127.0.0.1 for localhost). When the workflow executes the HTTP request, isDeniedIP() checks the resolved address against the IPv4 CIDR deny-list, but because ipaddr.js classifies the address as ipv6, those IPv4 checks are silently skipped and the request proceeds. The request reaches the cloud instance's metadata endpoint, which returns temporary IAM credentials in the HTTP response body; if the workflow surfaces raw HTTP responses back to the user (a common pattern in API Chain / HTTP Node outputs), the attacker receives the credentials directly and pivots to other cloud resources in the account.
Weaknesses (CWE)
CWE-1389Incorrect Parsing of Numbers with Different RadicesPrimaryCWE-1389Incorrect Parsing of Numbers with Different RadicesPrimaryCWE-918Server-Side Request ForgeryPrimaryCWE-918Server-Side Request Forgery (SSRF)PrimaryCWE-1389Incorrect Parsing of Numbers with Different RadicesCWE-918Server-Side Request ForgeryCWE-1389 — Incorrect Parsing of Numbers with Different Radices: The product parses numeric input assuming base 10 (decimal) values, but it does not account for inputs that use a different base number (radix).
- [Implementation] If only decimal-based values are expected in the application, conditional checks should be created in a way that prevent octal or hexadecimal strings from being checked. This can be achieved by converting any numerical string to an explicit base-10 integer prior to the conditional check, to prevent octal or hex values from ever being checked against the condition.
- [Implementation] If various numerical bases do need to be supported, check for leading values indicating the non-decimal base you wish to support (such as 0x for hex) and convert the numeric strings to integers of the respective base. Reject any other alternative-base string that is not intentionally supported by the application.
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2025-7133810.0Flowise: unauthenticated file write enables RCE
Same package: flowiseCVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same package: flowiseCVE-2025-619139.9Flowise: path traversal in file tools leads to RCE
Same package: flowiseCVE-2026-409339.9Flowise: RCE via MCP stdio command injection
Same package: flowiseCVE-2026-464429.9Flowise: sandbox escape enables authenticated RCE
Same package: flowise