CVE-2026-73483: Flowise before 3.1.3 Sandbox Escape via Puppeteer
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.
Security readout for executives and security teams
Plain-English summary
Authenticated Flowise users may turn custom JavaScript functions into operating-system commands, escaping the intended sandbox. Successful compromise can expose or alter sensitive data and disrupt the service. Impact is especially severe when Flowise runs as root, as identified for the official Docker image.
Executive priority
Treat as an immediate remediation priority where affected Flowise deployments permit custom functions. Prioritize root-running containers, exposed services, sensitive host mounts, and environments with multiple or less-trusted authenticated users. Upgrade promptly and investigate suspicious activity; widespread active exploitation is not established by the supplied evidence.
Technical view
Flowise and flowise-components through 3.1.2 permit a vm2/@flowiseai/nodevm sandbox escape through the custom-function API. Attacker-controlled Puppeteer launch parameters reach child_process.spawn outside the sandbox, enabling commands as the Flowise process user and host-file disclosure through Chromium file URLs. Versions 3.0.8–3.1.2 require ALLOW_BUILTIN_DEP=true; earlier affected versions are exploitable by default.
Likely exposure
Exposure requires an authenticated account able to access /api/v1/node-custom-function. Risk is highest for internet-accessible deployments, untrusted or compromised users, ALLOW_BUILTIN_DEP=true, sensitive host mounts, or execution as root. The supplied evidence does not quantify deployment prevalence.
Exploitation context
The vulnerability has low stated attack complexity and requires no user interaction, but does require privileges. It is not listed as KEV in the supplied bundle, and the cited information does not establish active exploitation in the wild. Public advisories describe the underlying escape mechanism.
Researcher notes
The trust-boundary failure occurs when sandbox-controlled Puppeteer options cause process creation outside vm2/@flowiseai/nodevm. Potential impact spans host confidentiality, integrity, and availability under the Flowise account. Exact pre-3.0.8 configuration conditions and indicators of compromise are not fully detailed in the supplied bundle.
Mitigation direction
Upgrade Flowise and flowise-components to version 3.1.3 or later.
Restrict custom-function API access to trusted administrators until upgrading.
Disable ALLOW_BUILTIN_DEP where operationally possible, particularly on versions 3.0.8–3.1.2.
Avoid running Flowise as root and minimize accessible host files and mounts.
Review the vendor advisory for any additional deployment-specific guidance.
Validation and detection
Inventory Flowise and flowise-components versions; identify deployments running 3.1.2 or earlier.
Confirm whether users can access /api/v1/node-custom-function.
Check whether ALLOW_BUILTIN_DEP is enabled on versions 3.0.8–3.1.2.
Determine the Flowise process user and whether official Docker deployments run as root.
Review authentication, API, process, and file-access logs for suspicious custom-function activity.
Verify the installed version reports 3.1.3 or later after remediation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · medium confidence lookup
CWE-78: Command execution behavior lookup
Command injection weaknesses can lead defenders to review execution techniques and command interpreter telemetry. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references privilege impact, so privilege escalation and authorization behavior review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
The affected technology mentions containers, so container-specific ATT&CK technique review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
3Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: pocAutomatable: yesTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-78 · source CWE mapping
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.