The vulnerability in Flowise stems from a fundamental mismatch between what the tool promises and how it was built. Flowise markets itself as a visual, no-code platform for assembling LLM workflows. Under the hood, components like AgentAsTool, ChatflowTool, and ExecuteFlow generate JavaScript at runtime using string interpolation with user-supplied input — specifically the baseURL parameter. This is code generation via string interpolation, the same genetic weakness that has produced SQL injection, template injection, and command injection across every ecosystem.
The defense was a validation function called isValidURL. This is the critical failure: the code checks whether a string is a valid URL format, but a valid URL can still contain characters that break out of JavaScript string context when interpolated into generated source code. URL validation addresses the functional requirement ('is this a real URL') but completely misses the security requirement ('can this string escape its syntactic context'). This is a recurring pattern — developers validate input appearance rather than input safety in code-generation contexts.
The vm2 sandbox was used to contain the generated code. vm2 has a documented history of sandbox escape vulnerabilities. Using a known-vulnerable sandbox for code generation with user-controlled input compounds the failure: even if the interpolation were corrected, the isolation mechanism itself is unreliable.
The fix in version 3.1.3 passes URLs as data parameters rather than interpolating them into generated source code — this is the correct solution. But the deeper question is how many other Flowise components use the same code-generation pattern. Agentic workflow support has expanded significantly since the initial release, and each new component that reaches for string interpolation to pass user input into generated code is a potential recurrence of this flaw.
For defenders: audit your Flowise deployment for components that generate JavaScript at runtime. Any component interpolating user-controlled strings into generated code represents this pattern. If you're building internal tooling on Flowise, assume authenticated users are potential attackers — the tool's no-code interface means non-technical users can achieve the same impact as a skilled exploit developer. Consider deploying Flowise with authentication mandatory and network segmentation, since the blast radius includes everyone with an authenticated session. For security teams reviewing code generation patterns in any product, automated detection via Semgrep or CodeQL rules targeting 'user input interpolated into generated source code' would catch this class of flaw before it ships.