Flowise Custom-Function Endpoint Authorization Bypass Leading to Host RCE
Missing route-level auth on POST /api/v1/node-custom-function plus a NodeVM sandbox escape yields authenticated code execution as the Flowise process user
FlowiseAI Flowise versions 3.1.1 and earlier expose POST /api/v1/node-custom-function without the authorization middleware applied elsewhere in the app, letting any authenticated user or API key submit raw JavaScript to the Custom Function node. When the optional E2B_APIKEY isolated-sandbox integration isn't configured — the default in most self-hosted setups — Flowise runs that code in a Node.js vm/NodeVM sandbox that can be escaped through its error-object constructor chain, handing the attacker child_process access on the host. The result is authenticated remote code execution as the Flowise service account, with full read/write over stored credentials, chatflows, and any connected systems. Fixed in 3.1.2 — upgrade immediately.
Technical Breakdown
Flowise Custom-Function Endpoint Authorization Bypass Leading to Host RCE
POST /api/v1/node-custom-function is the route backing Flowise's Custom JS Function node — it accepts arbitrary JavaScript in the request body and executes it server-side so low-code flows can run custom logic. Every other mutating route in the Express app is wrapped in Flowise's permission-checking middleware; this one was registered without it, so the role check that would normally gate function creation to authorized users never runs. Any caller holding a valid session or API key — no admin role required — can hit the route directly. When the optional E2B_APIKEY isolated-sandbox integration isn't configured, which is the default for most self-hosted installs, execution falls back to a Node.js NodeVM context instead of refusing outright. NodeVM's isolation wraps the outer realm's built-ins but doesn't fully sever the error-object constructor chain: a deliberately thrown error inside the sandboxed function resolves its .constructor.constructor back to the real, un-sandboxed Function constructor in the host realm. From there, calling process.getBuiltinModule("child_process") hands the attacker a working shell primitive against the actual OS process — a full sandbox escape with no further exploitation required.
Root Cause
The custom-function route was added to the API surface without applying the same permission-gating middleware every other flow-mutation endpoint uses, and the fallback path for a missing E2B_APIKEY defaults open — silently degrading to NodeVM — instead of failing closed and refusing execution.
Vulnerable Pattern
Executing user-supplied JavaScript in an in-process VM (Node's vm module / NodeVM-style sandbox) and trusting that boundary as a real security control, rather than isolating untrusted code in a separate process, container, or microVM with no shared memory space.
Why AI Services Are High-Value
Flowise instances broker live credentials for every LLM provider, vector store, and downstream integration a team has wired into its agent flows. A single compromised instance often yields more usable secrets than a decade-old app server, and the chatflow logic itself is a ready-made vector for supply-chain-style abuse against every system the agent touches.
The Fix
Upgrade to Flowise 3.1.2, which restores the permission middleware on the custom-function route. There is no viable pre-patch workaround — enforcing E2B_APIKEY only isolates execution, it doesn't restore the missing authorization check itself.
Attack Chain
Recon: fingerprint a reachable Flowise instance
Attacker scans for exposed Flowise deployments (default port 3000, /api/v1/ REST surface, distinctive branding) and confirms version ≤3.1.1 via headers/asset hashes.
Defensive note: Don't expose the Flowise admin/API surface directly to the internet; if it must be reachable, put it behind a reverse proxy that strips version-identifying headers and log all requests to /api/v1/* for anomaly review.
Obtain low-privilege credentials
Attacker acquires any valid session or API key via a leaked key, open self-registration, weak defaults, or phishing. No admin role required since the target endpoint has no permission gate at all.
Defensive note: Audit who holds Flowise API keys and disable open self-registration; rotate any keys that may have leaked (check .env files in repos, CI logs, shared docs).
Submit malicious payload to the unguarded endpoint
Using the valid credential, attacker sends crafted JS to POST /api/v1/node-custom-function, bypassing the missing route-level authorization.
Defensive note: Grep proxy/app access logs for POSTs to node-custom-function from accounts that don't normally build flows, and for unusually large or obfuscated JS payloads in the request body.
Escape the NodeVM sandbox
With E2B_APIKEY unset, execution falls back to NodeVM. The payload throws a crafted error whose constructor chain resolves to the outer Node realm, recovering the real Function constructor and calling process.getBuiltinModule("child_process").
Defensive note: A runtime JS-payload filter in front of the endpoint can catch known escape idioms (constructor.constructor, getBuiltinModule, process.mainModule) as a stopgap — not a substitute for patching.
Execute host commands / establish persistence
With child_process access, attacker runs arbitrary OS commands as the Flowise service user: exfiltrate stored LLM API keys and datasource credentials, pivot to connected systems, drop a reverse shell or cron persistence.
Defensive note: Run Flowise under a non-root, least-privilege service account with no filesystem access outside its data directory; alert on unexpected child processes spawned by the Flowise process (EDR/auditd execve monitoring keyed to the Flowise PID tree).
Impact
Low-code agent platforms like Flowise centralize secrets and execution power in one process, so a single auth-bypass-to-RCE chain converts one weak endpoint into full control of every credential and downstream system the platform touches.
Credential & Secrets Theft
- Flowise stores third-party LLM API keys and integration secrets, all readable after host code execution
- child_process access exposes environment variables (E2B_APIKEY, DB connection strings, session secrets)
- Stolen LLM provider keys enable billing fraud at the victim's expense
- Cached OAuth tokens for connected tools (CRMs, ticketing systems, cloud APIs) are exposed
Full Host Compromise
- RCE runs as the OS user hosting the Flowise process, often broader in privilege than intended
- Attacker can install persistence: cron entries, SSH authorized_keys, background services
- Lateral movement to any system reachable from the Flowise host's network position
- In unhardened containers, escape to the container runtime/orchestration layer (Docker socket, K8s service token) is a secondary risk
Data Integrity & Business Logic Abuse
- Attacker can silently modify chatflows/agent logic to exfiltrate future inputs or inject malicious prompts downstream
- Chatflow outputs, stored datasets, and evaluator results can be tampered with undetected
- Compromised flows can be weaponized against other systems the agent has tool access to
- Trust in agent-produced output collapses once the underlying flow definitions can't be verified as unmodified
Defensive Tutorial
Patch to Flowise 3.1.2 or later
ImmediateThis is the only complete fix. Verify the running version with npm ls flowise, or check the running container's image tag against [email protected].
Audit access logs for exploitation
ImmediateGrep for POST /api/v1/node-custom-function from accounts that don't normally author flows: grep -E 'POST /api/v1/node-custom-function' access.log | awk '{print $1, $NF}' | sort | uniq -c. Flag hits from non-admin/unfamiliar source IPs.
Rotate all secrets accessible to the Flowise process
ImmediateLLM provider keys, vector DB credentials, session/JWT signing secrets, and the E2B_APIKEY value itself if one was set.
Check for unauthorized child processes/persistence
ImmediateInspect for unexpected cron entries, new SSH authorized_keys, or lingering shell processes under the Flowise service account's UID.
Set and enforce E2B_APIKEY for isolated sandbox execution
ImportantConfirm that, post-3.1.2, custom-function execution fails closed rather than silently falling back to NodeVM when the key is missing.
Restrict network exposure
ImportantMove the admin/API surface behind a VPN or IP allowlist; WAF-block POST bodies to node-custom-function containing sandbox-escape idioms (constructor.constructor, getBuiltinModule, process.mainModule.require).
Move to least-privilege API keys
ImportantAudit existing Flowise API keys, scope each to only needed endpoints, and revoke broad/legacy keys that predate role separation.
Run Flowise under a dedicated, non-root, low-privilege service account
ImportantNo access to secrets or infrastructure beyond what the process strictly requires — this contains the blast radius of any future execution primitive, not just this one.
Add Flowise to SBOM/dependency tracking
ImportantSubscribe to FlowiseAI's GitHub Security Advisories — this vendor has shipped several critical RCEs in 2025-2026 (CVE-2025-59528, CVE-2026-40933, CVE-2026-41264, plus this one), a systemic pattern in how it handles user-supplied code execution, not an isolated bug.
References
- NVD Entry CVE-2026-46442 — CVSS v3.1 vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, base score 9.9.
- GitHub Security Advisory GHSA-9rvc-vf7m-pgm2 — vendor advisory with patch details and disclosure timeline, credited to researcher ESPanda666.
- Vendor Fix Release [email protected] — release confirming the patch, May 2026.
- CWE Reference CWE-94 — Improper Control of Generation of Code ('Code Injection')