CVE-2026-34156 is a critical (CVSS 9.9) sandbox escape in NocoBase's workflow script node. An authenticated user can break out of the Node.js vm sandbox and run code as root. The fix is in version 2.0.28, so upgrade to that release or later.
What's affected
The project's advisory (GHSA-px3p-vgh9-m57c) lists the npm package @nocobase/plugin-workflow-javascript at version 2.0.27 and earlier, with 2.0.28 as the patched release. The pull request and release linked in the record match that version.
The flaw needs an authenticated user who can create or test workflow script nodes. That limits who can use it, but in many installs a good number of staff hold builder roles. The record's vector shows low privileges required.
The advisory also notes the code ran as root in the deployment it tested. Whether yours does depends on how you run NocoBase.
How to check if you're exposed
Find the installed plugin version in your project:
npm ls @nocobase/plugin-workflow-javascript
For Docker deployments, check the image tag and confirm it is 2.0.28 or newer, then check inside the container if you build your own image.
Then look at who can build workflows. In the NocoBase admin, review the roles that can create or edit workflows and test script nodes. Remove that right from anyone who does not need it.
Also check whether the process runs as root:
ps -o user,pid,cmd -C node
If the application runs as root, a sandbox escape reaches everything on that host or container.
A lockfile scan covers many NocoBase projects quickly. Paste a lockfile or manifest into the free in-browser dependency scan to see whether the package is in your tree, including as a transitive dependency. Reachability analysis then helps you judge whether your code calls the affected path, so you can order the work sensibly.
Search the deployment for the script node feature. In the NocoBase admin, list existing workflows that contain a script node, and note who created or last edited each one. A script node you cannot explain is worth a closer look.
Review the configured module allowlist, which the advisory says is controlled by the WORKFLOW_SCRIPT_MODULES environment variable. Print what the process sees:
printenv WORKFLOW_SCRIPT_MODULES
The allowlist limits which modules a script can require, but the advisory shows that a leaked host object can sidestep it. Keep the list short, and do not treat it as isolation.
What to do now
- Upgrade NocoBase and the workflow script plugin to 2.0.28 or later.
- List the users and roles who can create, edit or test workflow script nodes, and remove the right from those who do not need it.
- Run the application as a non-root user, as the advisory recommends.
- Review existing workflow script nodes for code you do not recognize.
- Limit the module allowlist for workflow scripts to what you truly use.
- Treat the host as suspect if untrusted users held builder rights on a vulnerable version, and check for unexpected processes and files.
- Consider replacing in-process script execution with an isolate or a sandboxed worker process for any code written by users.
Why it matters
The record lists CWE-913, improper control of dynamically managed code resources. The advisory explains the mechanism at a high level: NocoBase ran user-supplied JavaScript inside a Node.js vm context, with a limited list of allowed modules. But the console object passed into that context belonged to the host, and exposed host-realm stream objects. From those objects, a script could reach the host's own constructors, step out of the sandbox and use the full Node.js runtime.
The lesson applies well beyond NocoBase. The Node.js documentation itself says the vm module is not a security mechanism. Anything you hand into the context, including console, can be a bridge back to the host. Real isolation needs a separate process, a container or a purpose-built isolate, and the advisory suggests moving to isolated-vm for that reason.
The record does not mark this CVE as exploited, and it is not on the CISA KEV list.
The advisory ends with remediation advice that is worth acting on even after the upgrade. Use a true isolate such as isolated-vm instead of the Node.js vm module, so the script runs in a separate V8 isolate. Do not pass the host console object in. Create a clean wrapper that exposes only the methods scripts need. Run the application as a non-root user inside Docker. Restrict the endpoint used to test workflow nodes to administrators.
The advisory also notes other escape routes through V8 internals, so closing one hole in the context is not the same as building a boundary. That is the central point. The vm module separates global variables, but it shares the same process, the same heap and the same privileges.
If you cannot upgrade yet, shrink the audience. Few people need to write script nodes. Take the right away from everyone else, and watch the process list for child processes that the application does not normally start:
ps -ef --forest | grep -A3 node
A node process that spawns a shell is a sign worth investigating.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is a vm sandbox safe for running user scripts?
Not on its own. Objects passed into the context can give scripts a way back to the host. Use stronger isolation and run the app without root.
Sources
Last reviewed: 19 October 2026.
