Safeguard
Vulnerability Analysis•

CVE-2026-69257: High SSRF Deny List Bypass in Flowise

Flowise before 3.1.3 does not normalize IPv4-mapped IPv6 addresses, so its SSRF deny list can be bypassed to reach internal services. Upgrade to 3.1.3.

Safeguard Security Team
4 min read

CVE-2026-69257 is a high severity (CVSS 8.6) server side request forgery flaw in Flowise. Before 3.1.3, its deny list did not normalize IPv4-mapped IPv6 addresses, so crafted requests can reach localhost, internal services or cloud metadata endpoints from the server. Upgrade to Flowise 3.1.3 and restrict egress.

What's affected

The record says Flowise before 3.1.3 is affected, and that the issue is fixed in 3.1.3. Fixed in Flowise 3.1.3, which the project published as a GitHub release. The release page I retrieved shows the repository as archived and read only by its owner since 13 August 2026. That does not change the advice to run 3.1.3 or later, but it does mean you should check where future security fixes will come from before you rely on this project long term.

The record says httpSecurity.ts did not normalize addresses such as the IPv4-mapped form of localhost or of the link local metadata address before checking the deny list. The IP library reports them as IPv6 while the deny entries are IPv4 ranges, so the IPv4 checks were skipped. An attacker who controls DNS for a hostname used by the HTTP node, API Chain, Document Loader, MCP tool or other paths could return a matching AAAA record.

I relied on the record for the technical description of this CVE. The 3.1.3 release page was the only vendor page I retrieved, and it does not give a per-CVE explanation.

How to check if you're exposed

npm ls -g flowise
docker image ls | grep -i flowise

The first command shows a global npm install, the second any Flowise container image and its tag. If you run it from a compose file or a Kubernetes manifest, read the image tag there. Anything below 3.1.3 is in scope.

Then find who can reach the affected feature. In most deployments the first control is who holds a login or an API key, so list those too. Every path described in the record needs some level of access, or in the unauthenticated case, only network reach to the service.

A quicker route for a whole project is the free in-browser dependency scan at Gold. Paste a manifest or lockfile and it matches each dependency against known CVEs, including ones pulled in indirectly.

What to do now

  1. Upgrade Flowise to 3.1.3 or later and redeploy all instances, including containers built from older images.
  2. Block outbound traffic to localhost, private ranges and the metadata address at the network layer, not only in application code.
  3. Require token based metadata access (such as IMDSv2 on AWS) and give the instance role the least privilege.
  4. Review which flows use HTTP, API Chain, Document Loader and MCP tool nodes with user provided URLs.
  5. Apply egress filtering that handles both IPv4 and IPv6 forms of an address.
  6. Check whether the project's archived status affects your support plan, and decide on an owner for security updates.
  7. Run Flowise behind authentication and a network boundary, and do not expose its admin or API ports directly to the internet.

Reachability analysis helps with ordering the work. Knowing whether your code actually calls the affected path tells you which services to patch first.

Why it matters

Two weaknesses are tagged: CWE-918, server side request forgery, and CWE-1389, incorrect parsing of numbers with different representations. The same address can be written more than one way, and a filter that compares one spelling misses the other.

The practical danger is cloud metadata. Reaching the instance metadata service from the server can yield credentials for the host's cloud role. If you run Flowise in a cloud account, enforce IMDSv2 or its equivalent and restrict the role's permissions. The record does not mark this CVE as known exploited.

Try it yourself

This demo shows how an API security scan finds server side request forgery and similar issues in endpoints that fetch URLs.

Click through it at your own pace, or open it full screen.

Quick check

Why does IPv6 matter if my network is IPv4?

The record describes an IPv4-mapped IPv6 form that still reaches IPv4 destinations, while the filter treated it as IPv6 and skipped its IPv4 rules.

What is the worst case?

Reaching cloud metadata or internal services from the Flowise host, per the record.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.