CVE-2026-73602 is a critical (CVSS 9.9) sandbox escape in the JavaScript sandbox used by Flowise before 3.1.3. An authenticated user who can build flows can run code outside the sandbox on the server. The fix is Flowise 3.1.3, so upgrade and review who has builder access.
What's affected
Flowise through version 3.1.2, fixed in 3.1.3, per the GitHub advisory. The affected feature is custom JavaScript, in the Custom Function and Custom Tool nodes, which runs in a sandbox built on a fork of the vm2 library.
The attacker needs a login, since the record says authenticated users. In an instance where many people can build flows, that is a wide group. The advisory reproduces an elttam disclosure from April 2026 against Flowise 3.1.1.
How to check if you're exposed
Check the version.
npm ls flowise
Then review who has accounts and who can create or edit flows with Custom Function or Custom Tool nodes. If anyone untrusted can, consider that a higher exposure.
What to do now
- Upgrade Flowise to 3.1.3 or later.
- Remove builder access from accounts that do not need it.
- Run Flowise in a container or under a dedicated low privilege user, with no access to unrelated secrets.
- Review existing Custom Function and Custom Tool nodes for code you do not recognize.
- Plan a move away from in-process JavaScript sandboxes for untrusted code where you can.
Why it matters
The record maps this to CWE-95, eval injection. The advisory says the sandbox runs code inside the same Node.js process as the app. The vm2 project had been deprecated by its maintainers, with a warning that it should not be used in production, and it recommended isolated-vm instead.
A sandbox that lives in the same process as the thing it protects is hard to make airtight. One missed check lets code reach the host. Stronger isolation means a separate process, container, or virtual machine.
The KEV flag is false and the record does not describe exploitation.
Reviewing builder access
This flaw requires a login, so the best long term control is the list of people who can create flows. Many teams give everyone builder rights because it is convenient. Review the accounts, remove people who only need to use flows, and make sure that shared or departed accounts are gone. Use strong passwords and, where the product supports it, single sign-on.
Sandboxes inside the process
The advisory notes the sandbox runs in the same Node.js process as the application, and that the upstream library had been discontinued with a warning not to use it in production. Software that depends on an abandoned security component carries a standing risk, because each new bypass will have no upstream fix. If you build products that run user supplied code, prefer isolation that the operating system enforces: a separate process with reduced privileges, a container, or a virtual machine. For Flowise users, the practical step is to patch and to limit who can create nodes that run custom JavaScript.
The free in-browser dependency scan at gold.safeguard.sh/scan can show whether a project you maintain pulls in an affected package, and the Gold vulnerability directory keeps the record for this CVE.
Quick check
Who can exploit CVE-2026-73602?
An authenticated user who can create or edit flows with custom JavaScript, according to the record.
Sources
Last reviewed: 19 October 2026.
