Safeguard
Vulnerability Analysis•

CVE-2025-34267: Critical Sandbox Escape RCE in Flowise

CVE-2025-34267 is a critical authenticated RCE and sandbox escape in Flowise 3.0.1 to before 3.0.8. Upgrade to 3.0.8 and keep ALLOW_BUILTIN_DEP off.

Safeguard Security Team
4 min read

CVE-2025-34267 is a critical (CVSS 9.9) authenticated remote code execution and Node VM sandbox escape in Flowise from 3.0.1 to before 3.0.8, and later versions with ALLOW_BUILTIN_DEP enabled. Upgrade to 3.0.8 or later and leave that setting off unless you truly need it.

What's affected

The record says Flowise versions from 3.0.1 up to but not including 3.0.8 are affected, and so are all versions after that where the ALLOW_BUILTIN_DEP setting is enabled. The fix named by the record is 3.0.8.

The linked pull request number 5231 changes the default so the built-in dependencies available to custom function nodes are only allowed when ALLOW_BUILTIN_DEP is set to true. It was merged on 18 September 2025. The pull request does not name a release, and one follow-up report says some existing flows broke after the change, so test your flows after upgrading.

The record also notes the CVE was wrongly assigned as a duplicate of CVE-2025-26319 by the developers and is distinct from it.

How to check if you're exposed

Find the installed Flowise version. For an npm install:

npm ls flowise

For Docker, check the image tag in your compose file or run docker image ls on the Flowise image. A version from 3.0.1 to below 3.0.8 is in range.

Then check the environment of the running service for ALLOW_BUILTIN_DEP:

env | grep ALLOW_BUILTIN_DEP

If it is set to true, you are in range even on a newer version. Also review who has accounts, since an authenticated user who can create or run tools is required. For your own projects that depend on Flowise or related packages, the free in-browser scan can list known issues in your manifest.

What to do now

  1. Upgrade Flowise to 3.0.8 or later.
  2. Check that ALLOW_BUILTIN_DEP is unset or false, and enable it only if you truly need it and trust every user who can build tools.
  3. Review user accounts and remove any that do not need the right to create or run tools.
  4. Run Flowise as a low privilege user in a container with no access to secrets you do not need on that host.
  5. Restrict network egress from the Flowise host.
  6. Review existing custom tools and function nodes for ones that use browser automation with unusual paths or parameters.
  7. Test your flows after the upgrade, since the change affects built-in dependencies.

Why it matters

The record classifies this as CWE-77, command injection. It describes an escape from the Node VM sandbox through the Puppeteer and Playwright modules that were reachable inside it. A user who can create or run a tool can pass browser binary paths and parameters, so the host ends up running the attacker chosen executable outside the sandbox limits.

The broader lesson for AI workflow builders is that a sandbox is only as strong as the modules you let into it. Anything that can start a process is an escape route. Reachability analysis helps here, because it shows whether your code calls the risky module at all instead of listing every package that carries it. The CVSS scope is changed (S:C), meaning impact extends beyond the vulnerable component to the host. The record does not flag exploitation in the wild and the CVE is not on the CISA KEV list.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Am I safe on a version newer than 3.0.8?

Only if ALLOW_BUILTIN_DEP is not enabled. The record says later versions with that setting on are affected too.

Who can exploit this?

An authenticated user who can create or run a tool, per the record.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.