Flowise Sandbox Escape Lets Authenticated Users Achieve RCE via vm2 and a Moment.js Locale Bypass

What happened

Security researchers at elttam (Luke Jahnke and Alex Brown) disclosed a JavaScript sandbox escape in FlowiseAI/Flowise, tracked as CVE-2026-69253, affecting Flowise 3.1.1 and the FlowiseAI/nodevm package (a fork of the deprecated patriksimek/vm2). According to the advisory, Flowise's Custom Function Agent Flow and Custom Tool nodes execute user-supplied JavaScript inside a vm2-based sandbox that also exposes the moment library. The researchers found that a previously patched moment path-traversal issue (CVE-2022-24785) can be bypassed from inside the sandbox by supplying a fake object whose match() method always returns true, defeating the locale-name validation and enabling arbitrary file requires outside the sandbox.

The advisory further reports that several Flowise components — including the AgentAsTool, ChatflowTool, and ExecuteFlow nodes — still run with useSandbox: false (bypassing even the newer E2B-based sandbox), and that these paths inject an attacker-controlled baseURL value into sandboxed code without adequate validation, due to a broken isValidURL check that doesn't account for URL hash-fragment characters. The advisory documents a full proof-of-concept chain, using the AgentAsTool node's baseURL field to inject the sandbox-escape payload and achieve a reverse shell as the node user in a Docker deployment. It notes the report was originally, and incorrectly, closed as a duplicate of the known outdated-vm2 issue — the maintainers confirmed the underlying escape is a Flowise-specific issue that persists even against the latest commit on the main branch at time of writing, and that simply updating vm2 does not fix it.

Why it matters for defenders

Flowise is a widely used low-code platform for building AI chatbots, workflows, and agents, and its custom-code nodes are a core feature for many deployments. Per the advisory, exploitation requires an authenticated user able to create/modify chatflows and document stores — but any organization allowing multiple users (or exposing Flowise instances with default/weak credentials) should treat this as a path to full server compromise, not just sandbox misuse. The impact described is complete compromise of the host running Flowise, including access to stored credentials, connected services, and any data reachable from that host.

What defenders should watch for or do now

• Inventory any self-hosted Flowise instances and check whether Custom Function, Custom Tool, AgentAsTool, ChatflowTool, or ExecuteFlow nodes are in use, and whether E2B_APIKEY is configured (the advisory notes several code paths bypass the E2B sandbox regardless).
• Review who has authenticated access to create or edit chatflows/agentflows and document stores — the PoC relies on an authenticated user chaining document-store file uploads with a crafted baseURL field.
• Watch for anomalous child-process activity spawned from the Flowise Node.js process (e.g., shells, netcat, unexpected outbound connections) and for file-read activity outside the application's storage directories from the Flowise process.
• Monitor for suspicious baseURL values containing URL fragment characters (#) followed by JavaScript-like syntax in chatflow configuration changes (PUT /api/v1/chatflows/*) and unusual document-store uploads of script-like files.
• Per the advisory, updating the vm2/nodevm package alone will not remediate this; the recommended mitigation is migrating custom code execution away from vm2-style in-process sandboxes to a properly isolated execution model such as isolated-vm, and ensuring sandboxing (e.g., E2B) is consistently enforced across all nodes rather than selectively disabled.

Developing intel

This is a same-day advisory publication and details may evolve as the vendor responds and a fix lands. We'll track this item for updates. Full technical details, including the complete proof-of-concept request, are available in the original elttam/GitHub Security Advisory: GHSA-wg86-r78f-74mp.