Authenticated users can escape Flowise and n8n code nodes to run OS commands. n8n is fixed in 2.42.6, 2.43.3 and 3.0.1; Flowise 3.1.4 has no fix and is archived.
Two workflow-automation platforms popular for AI agent pipelines have disclosed authenticated remote code execution flaws in the nodes that run user JavaScript. NVD published both records on 30 October 2026, each with VulnCheck as the source. n8n has shipped fixes. Flowise has not: as of 5 November 2026 its latest release is still 3.1.4, and the GitHub repository is archived. None of the sources we read reports exploitation in the wild.
Flowise: CVE-2026-119978 (no fix)
Flowise through 3.1.4 is affected. An authenticated user can submit JavaScript to /api/v1/node-custom-function that writes a file into the mammoth package through LocalFileStore and then requires it. That escapes the vm2 sandbox and runs OS commands as the Flowise process user. VulnCheck scores it CVSS 4.0 9.0 (Critical) and CVSS 3.1 8.5 (High), CWE-749.
The exploit needs ALLOW_BUILTIN_DEP=true. According to the researcher's write-up (credited to soovwv), that setting is not the default: the shipped docker/.env.example leaves it commented out, and the default external allowlist is only axios and node-fetch, under which the author reports the chain does not work. The attacker needs valid credentials; the write-up says an account with create or update permission on chatflows or agentflows, or an API key, is enough.
The write-up's root cause is that the sandbox allowlist matches package directories, not files, so packages without an exports map expose every file in the folder. Allowlisted libraries then run with host privileges, and one of them can write files anywhere on disk. The author says the 3.1.3 fix removed nine names from the allowlist but 58 remain, and that 13 of 23 remaining packages without an exports map reached host execution. These are the researcher's claims from their own testing.
Do not confuse this with GHSA-9gvv-qjj3-2p6g (CVE-2026-73483), an earlier Flowise sandbox escape on the same endpoint via a puppeteer allowlist entry, affecting 3.1.2 and earlier and fixed in 3.1.3. NVD lists it only as a reference. Upgrading to 3.1.3 or 3.1.4 does not fix CVE-2026-119978.
What Flowise operators should do
The VulnCheck page gives no mitigation, so the following comes from the researcher and from the stated precondition.
- Check that
ALLOW_BUILTIN_DEPis unset orfalse, in every environment file, container definition and orchestrator config. This removes the stated precondition. - If you must enable it, mount the application tree read-only. The author says this breaks the file-write step, though read-based primitives remain.
- Restrict who holds chatflow and agentflow create/update permissions and who holds API keys. Rotate keys you cannot account for.
- Do not expose the instance, or
/api/v1/node-custom-function, to untrusted networks; put it behind a VPN or authenticating proxy. - Run the process as a non-root user with minimal secrets and network egress, since the code runs as the Flowise user.
- With the repository archived and no release after 3.1.4, plan a migration or a maintained fork; the researcher notes that removing individual allowlist names will not fully close this class of bug.
n8n: CVE-2026-119408 (fixed)
The deprecated Function, Function Item and LangChain Code nodes run outside the task runner isolation that protects the current Code node. An authenticated user who can create, modify or import workflows using these hidden node types can run JavaScript in the n8n main process. Affected: versions below 2.42.6, 2.43.x below 2.43.3, and 3.x below 3.0.1. VulnCheck scores it CVSS 3.1 8.8 and CVSS 4.0 8.7 (High), CWE-653.
n8n's advisory (GHSA-9p7v-45m2-wxgj, published 28 October) says Function and Function Item use vm2 and LangChain Code runs directly in the main process. Abraxas Labs, which tested 2.42.0, found the nodes were only hidden from the editor palette and could still be resolved on workflow save or import; its test showed Function code in the main process while the Code node ran in a runner child. The researcher did not publish a full escape payload and its broader impact claims are inference. VulnCheck credits Abraxas Labs and mfsiega.
Because the main process holds instance configuration and credentials, a member account with workflow permissions is effectively a path to the host. This is separate from our earlier coverage of n8n queue-mode Redis write access and npm package install (CVE-2026-103251).
What n8n operators should do
- Upgrade to 2.42.6, 2.43.3 or 3.0.1 (the advisory also lists 2.44.0 as fixed).
- After upgrading, the three nodes are blocked by default: saving a workflow that adds or changes one is rejected, but existing workflows keep running. Find workflows that use
n8n-nodes-base.function,n8n-nodes-base.functionItemor@n8n/n8n-nodes-langchain.codeand replace them with the Code node. - Leave
N8N_DEPRECATED_NODES_BLOCKat its default; setting it tofalsere-enables the vulnerable behavior. - If you cannot upgrade yet, add those three node types to
NODES_EXCLUDEand limit workflow create, edit and import to fully trusted users. n8n calls these temporary measures, not remediation. - Review existing workflows and audit logs for unexpected use of these nodes, and rotate credentials if untrusted users had workflow access.
Similar CVSS scores, different status: n8n is patched, Flowise is not.
Why it matters
Both flaws sit in the same place: in-process JavaScript sandboxes (vm2) used as a security boundary for user-written code. The researchers on both sides describe that as unreliable. Exploitation needs authentication in each case, so exposure scales with how many people hold workflow-editing rights and how widely the service is reachable.