AI Threat AlertCVE-2026-73483: Flowise: sandbox escape via puppeteer.launch() to RCE
GHSA-9gvv-qjj3-2p6gCRITICALCISA: ATTENDFlowise's custom-function feature runs user-supplied JavaScript in a vm2-based sandbox, but an authenticated user can call puppeteer.launch() with attacker-controlled executablePath and args, which invokes child_process.spawn() outside the sandbox boundary and hands them arbitrary OS command execution — as root, in the official Docker image. This isn't a theoretical sandbox bug: it's full host compromise plus arbitrary file read via Chromium's file:// handling, reachable by any authenticated user of a self-hosted Flowise instance, which is a common low-code AI agent platform sitting on top of credentials, API keys, and connected data sources. There's no CISA KEV listing and no public exploit or Nuclei template yet (EPSS 0.37%, top 69th percentile), so this looks like a patch-now-not-panic situation rather than an active-exploitation emergency, but the vendor rated it critical and the fix is a one-line version bump. Upgrade to Flowise/flowise-components 3.1.3 or later immediately; if you're on 3.0.8–3.1.2 you can buy time by setting ALLOW_BUILTIN_DEP=false, but versions before 3.0.8 are exploitable regardless of that flag. Audit who has authenticated access to /api/v1/node-custom-function and check container logs for unexpected puppeteer/chromium child processes as a compromise indicator.
What is the risk?
Critical severity despite the absence of a published CVSS vector, KEV listing, or public PoC. The barrier to exploitation is low for anyone who already has an authenticated account on the Flowise instance — no social engineering or complex chaining required, just crafting a custom function that calls puppeteer.launch() with a malicious executablePath. Impact is maximal: arbitrary OS command execution running as root in the default Docker deployment, plus host file disclosure. The main mitigating factor is the authentication requirement and current lack of a mass-exploitation tool, which keeps EPSS low (0.37%) and SSVC at ATTEND rather than ACT — but any multi-tenant or externally-exposed Flowise deployment where users don't fully trust each other should treat this as urgent.
How does the attack unfold?
What systems are affected?
How severe is it?
What should I do?
1 stepUpgrade flowise and flowise-components to 3.1.3 or later immediately. If immediate upgrade isn't possible and you're running 3.0.8–3.1.2, set ALLOW_BUILTIN_DEP=false as a stopgap (does not help versions before 3.0.8, which are exploitable by default). Restrict access to /api/v1/node-custom-function to only trusted, need-to-know users via RBAC — treat this endpoint as equivalent to arbitrary code execution. Run the Flowise container as a non-root user regardless of patch status, and apply seccomp/AppArmor profiles plus a read-only root filesystem to limit blast radius from any future sandbox bypass. Detection: monitor for puppeteer/chromium/headless-shell child processes spawned by the Flowise process, unexpected outbound network connections from the container, and file:// URL requests in Chromium debug logs.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-73483?
Flowise's custom-function feature runs user-supplied JavaScript in a vm2-based sandbox, but an authenticated user can call puppeteer.launch() with attacker-controlled executablePath and args, which invokes child_process.spawn() outside the sandbox boundary and hands them arbitrary OS command execution — as root, in the official Docker image. This isn't a theoretical sandbox bug: it's full host compromise plus arbitrary file read via Chromium's file:// handling, reachable by any authenticated user of a self-hosted Flowise instance, which is a common low-code AI agent platform sitting on top of credentials, API keys, and connected data sources. There's no CISA KEV listing and no public exploit or Nuclei template yet (EPSS 0.37%, top 69th percentile), so this looks like a patch-now-not-panic situation rather than an active-exploitation emergency, but the vendor rated it critical and the fix is a one-line version bump. Upgrade to Flowise/flowise-components 3.1.3 or later immediately; if you're on 3.0.8–3.1.2 you can buy time by setting ALLOW_BUILTIN_DEP=false, but versions before 3.0.8 are exploitable regardless of that flag. Audit who has authenticated access to /api/v1/node-custom-function and check container logs for unexpected puppeteer/chromium child processes as a compromise indicator.
Is CVE-2026-73483 actively exploited?
No confirmed active exploitation of CVE-2026-73483 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-73483?
Upgrade flowise and flowise-components to 3.1.3 or later immediately. If immediate upgrade isn't possible and you're running 3.0.8–3.1.2, set ALLOW_BUILTIN_DEP=false as a stopgap (does not help versions before 3.0.8, which are exploitable by default). Restrict access to /api/v1/node-custom-function to only trusted, need-to-know users via RBAC — treat this endpoint as equivalent to arbitrary code execution. Run the Flowise container as a non-root user regardless of patch status, and apply seccomp/AppArmor profiles plus a read-only root filesystem to limit blast radius from any future sandbox bypass. Detection: monitor for puppeteer/chromium/headless-shell child processes spawned by the Flowise process, unexpected outbound network connections from the container, and file:// URL requests in Chromium debug logs.
What systems are affected by CVE-2026-73483?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, low-code AI orchestration, custom code execution nodes, self-hosted AI platforms.
What is the CVSS score for CVE-2026-73483?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0050Command and Scripting InterpreterAML.T0053AI Agent Tool InvocationAML.T0097Virtualization/Sandbox EvasionAML.T0105Escape to HostCompliance Controls Affected
What are the technical details?
Original Advisory
Flowise (packages flowise and flowise-components) in versions <= 3.1.2 contain a sandbox escape in the vm2/@flowiseai/nodevm JavaScript sandbox. An authenticated user with access to the /api/v1/node-custom-function endpoint can escape the sandbox by supplying attacker-controlled executablePath and args parameters to puppeteer.launch(), which internally invokes child_process.spawn() outside the sandbox boundary. This allows execution of arbitrary OS commands as the Flowise process user (root in the official Docker image) and arbitrary host file disclosure via Chromium's file:// URL handling. In versions 3.0.8–3.1.2 exploitation requires ALLOW_BUILTIN_DEP=true; earlier versions are exploitable by default. Fixed in 3.1.3.
Exploitation Scenario
An attacker with a low-privilege authenticated account on a shared or externally-exposed Flowise instance creates a new custom-function node in the workflow builder. Instead of legitimate business logic, the function calls puppeteer.launch() with executablePath pointing to /bin/sh and args containing a reverse shell one-liner; because puppeteer.launch() internally calls child_process.spawn() outside the vm2 sandbox boundary, the command executes directly on the host container as root. From there the attacker reads environment variables and mounted secrets, pivots to any internal services reachable from the container network, and can also use Chromium's file:// URL handling to exfiltrate arbitrary files (SSH keys, .env files, database credentials) from the container filesystem.
Weaknesses (CWE)
CWE-78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')PrimaryCWE-78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')CWE-78 — Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'): The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.
- [Architecture and Design] If at all possible, use library calls rather than external processes to recreate the desired functionality.
- [Architecture and Design, Operation] Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2025-7133810.0Flowise: unauthenticated file write enables RCE
Same package: flowiseCVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same package: flowiseCVE-2025-619139.9Flowise: path traversal in file tools leads to RCE
Same package: flowiseCVE-2026-409339.9Flowise: RCE via MCP stdio command injection
Same package: flowiseCVE-2026-464429.9Flowise: sandbox escape enables authenticated RCE
Same package: flowise