The CVSS 9.4 rating for CVE-2026-69254 captures root-level command execution, but the vulnerability's root cause is more instructive than the severity score suggests. This is not a bypass — it's a case where authentication was never the relevant access control layer in the first place.
The vulnerability lives in executeJavaScriptCode(), a component utility in packages/components/src/utils.ts designed for internal use. It accepted caller-controlled nodeVMOptions that could override its own security defaults. When this utility was exposed through the authenticated API route at /api/v1/node-custom-functions, an authenticated user could invoke it with parameters that weakened the NodeVM sandbox — specifically by enabling the child_process module. There was no exploit chain, no injection: the attacker called a legitimate function with modified parameters.
This reveals a fundamental architectural flaw: Flowise conflated 'authenticated caller' with 'authorized to modify security boundaries.' Authentication establishes identity, not intent. On a drag-and-drop LLM flow builder where authenticated users can write and execute JavaScript by design, the threat model should have distinguished between 'user executing code in their intended flow context' and 'user modifying the security contract of the execution engine itself.' That distinction was never drawn.
The fix in version 3.1.3 removes nodeVMOptions parameter flexibility. That closes this specific path, but the deeper question is whether the component utility layer as a whole — code that migrated from trusted internal context to exposed API without security reassessment — still operates under implicit trust assumptions. The recursive invocation pattern (executeJavaScriptCode() could call itself with modified parameters) existed before the patch and may still exist for other parameters.
Defenders running Flowise should verify they are on 3.1.3 or later. More importantly, audit any other component utilities that accept caller-controlled parameters affecting security boundaries — the nodeVMOptions removal addressed this one case, but the architectural assumption that 'authenticated caller equals authorized to set security parameters' may persist elsewhere in the packages/components layer.