The deny-list that forgot two clouds: SSRF to instance metadata in Flowise

Server-side request forgery is the vulnerability that turns your application server into an attacker's proxy, and in cloud environments its favorite destination is the instance metadata service. Reach that endpoint and you are usually one request away from the temporary role credentials the workload runs with. Flowise, the low-code builder for LLM apps, shipped an SSRF guard that was supposed to prevent exactly this, and in versions through 3.1.4 that guard has a gap you could drive a credential-theft campaign through: its deny-list forgot two entire clouds.

The intended control and the hole in it

Flowise implements an SSRF guard in httpSecurity.ts with a DEFAULT_DENY_LIST that is meant to block requests to sensitive internal addresses before the server fetches an attacker-influenced URL. The problem is not the idea, it is the completeness. The list omits the Oracle Cloud Infrastructure metadata endpoint at 192.0.0.192 and the Alibaba Cloud metadata endpoint at 100.100.100.200. Everyone remembers the AWS link-local address at 169.254.169.254. Far fewer deny-lists remember that OCI and Alibaba use different, non-link-local addresses for the same purpose. A deny-list is only as good as its worst omission, and here the omission is two production clouds' entire metadata surface.

An attacker reaches the sink through the fetch-links API endpoint with a crafted url parameter. Because the deny-list does not name those two metadata addresses, the validation passes and the server dutifully issues a GET to the metadata service. On OCI or Alibaba deployments that means the response can carry instance identity data and, more importantly, the role credentials attached to the instance.

Deny-lists lose, and redirects make them lose faster

There is a second, deeper lesson here. This advisory notes that the bypass includes redirect-based bypasses, which is the failure mode that makes URL deny-lists structurally weak. Even a deny-list that named every metadata address you can think of can be defeated by pointing the fetch at an attacker-controlled host that answers with a 302 to http://100.100.100.200/.... If the fetch logic follows redirects and only validated the original URL, the redirect target is never checked. The attacker never has to put the forbidden address in the request you inspect; they let your own HTTP client walk into it.

This is why mature SSRF defenses do not rely on enumerating bad destinations. They resolve the target, validate the resolved IP against allow-list ranges rather than a deny-list of known-bad ones, re-validate after every redirect, and refuse to follow redirects into private, link-local, or metadata ranges. Naming addresses to block is a game you lose one cloud provider at a time.

Why the authentication caveat barely helps

The base case requires an authenticated attacker, which sounds like a meaningful barrier until you read the rest. The advisory states unauthenticated access is possible when URL-fetching nodes exist in public chatflows. Flowise exists to let people build and expose chatflows, and a chatflow that fetches a URL is an entirely ordinary design. So the realistic exposure is not "an authenticated insider" but "any site that published a chatflow which fetches links," which is a configuration the product actively encourages. Treat the authentication requirement as advisory, not protective, and assume any internet-reachable Flowise with a link-fetching public flow is exploitable by anyone.

Blast radius

On an affected OCI or Alibaba deployment, the immediate prize is the instance's role credentials. Those credentials inherit whatever the workload was granted, and LLM orchestration servers are frequently over-permissioned because they touch object storage, secrets managers, databases, and internal APIs. From leaked instance credentials an attacker pivots to reading buckets, enumerating other resources under the role, and moving laterally inside the account. The SSRF is the entry, but the credential theft is the event that turns one vulnerable web app into a cloud-account incident.

How to tell if you are exposed

Inventory every Flowise instance and check the version against 3.1.4. If you run on Oracle Cloud Infrastructure or Alibaba Cloud, raise the priority, because those are the deployments the missing deny-list entries directly expose. Enumerate your chatflows for any node that fetches an external URL, and treat any such node reachable on a public chatflow as an unauthenticated SSRF surface. In your logs, look for calls to the fetch-links endpoint whose url parameter points at metadata addresses or at hosts that redirect toward them.

What to do today

Upgrade Flowise past 3.1.4. If you cannot upgrade immediately, put the control where the network can enforce it: block egress from the Flowise workload to 192.0.0.192, 100.100.100.200, 169.254.169.254, and the rest of the link-local and metadata ranges at the security group or host firewall, so a bypassed application-layer deny-list still hits a closed door. Move the instance to IMDSv2-style session-token metadata where your cloud supports it, and tighten the instance role to least privilege so a leaked credential is worth as little as possible. Then rotate any credentials that could have been exposed while an affected version was internet-reachable.

The general rule

When you see an SSRF guard built as a deny-list of addresses, read it as a list of the destinations the author remembered, not the destinations that matter. The safe pattern is to validate the resolved IP against an allow-list, re-check after every redirect, and enforce the same policy again at the network layer. We test URL-fetching features for exactly these bypasses, including the redirect chain, because the version banner tells you nothing about whether the deny-list remembered your cloud.

Reference

CELVEX Group tracks this issue in the scanner catalog and probes URL-fetch endpoints for metadata reachability and redirect-follow behavior rather than trusting a version string alone. Refer to the vendor advisory for patched-release details.