CVE-2026-72765 is a critical (CVSS 9.9) sandbox escape in n8n expression evaluation. An authenticated user who can create or edit workflows can run system commands on the host. Fixed in n8n 2.31.5 and 2.32.1. Upgrade, and limit who can edit workflows meanwhile.
What's affected
n8n before 2.31.5 on the 2.31 line, and before 2.32.1 on the 2.32 line. The fixed versions are 2.31.5 and 2.32.1, and the project says to upgrade to one of them or later.
The attacker needs a login with permission to create or modify workflows. On a team instance, that can include many people. The project's own advisory scores the issue 8.7 under CVSS 4.0 with low privileges required, while NVD scores it 9.9 under 3.1. Both treat it as serious.
The GitHub advisory names the n8n npm package. Docker images follow the same version numbers, so check the tag you run.
How to check if you're exposed
Check the version in whatever form you run n8n.
n8n --version
For Docker, run the same command inside the container.
docker exec <container> n8n --version
For an npm install, list it.
npm ls -g n8n
Then list the users on the instance and note which ones can create or edit workflows. If any are people you do not fully trust, treat the instance as higher risk.
What to do now
- Upgrade to 2.31.5 or 2.32.1, or any later release.
- Until then, restrict access to the n8n instance to fully trusted users, as the advisory suggests.
- Restrict workflow creation and editing permissions to trusted users only.
- Run n8n in a container or as a low privilege user, with narrow access to secrets and the network.
- Review credentials stored in n8n and rotate any you cannot account for.
- Review workflows for expressions you do not recognize.
Why it matters
The record maps this to CWE-94, code injection. n8n lets people write small expressions inside workflow fields, and it runs them inside a sandbox to keep them away from the host. The advisory says arrow function bodies could be used to get around that sandbox.
Expression sandboxes are hard because the language being restricted is a full programming language. Each new syntax feature is another path the filter has to understand. When a sandbox fails, the code runs with the n8n process's privileges, which on many installs include access to every credential the workflows use. That is why automation platforms are an attractive target.
The advisory is clear that restricting users is a short term measure that does not fully remove the risk. The KEV flag is false and no exploitation is described.
Reducing the damage a workflow editor can do
Automation platforms concentrate credentials. A single n8n instance may hold keys for email, chat, cloud accounts, databases and payment tools, and an expression that escapes the sandbox runs with access to all of it. So the question after patching is how much damage a future escape could cause.
A practical review has four parts. List the credentials stored in the instance and remove unused ones. Scope the remaining credentials to the least access that the workflows need, for example read only API tokens where writing is not required. Run the process as a dedicated unprivileged user, ideally in a container with no host mounts, and keep outbound network access to the services the workflows really call. And separate duties: people who build workflows for sensitive systems should be a short list.
Why expression sandboxes keep breaking
Expressions are a convenience feature. They let a person write one line of logic in a field. To make that safe, the platform has to allow a useful subset of a real programming language and block everything else. Each language feature, such as the arrow function bodies named in this advisory, creates a new way to reach objects the sandbox meant to hide. Fixes usually patch one route at a time, and the next route is found later. That is not a criticism of any one project. It is the nature of filtering a full language, and it is the reason the advisory pairs the patch with advice to restrict who can edit workflows.
If your instance serves only a small trusted team, the practical risk is lower than on one shared with outside collaborators or customers, though the patch is cheap enough that you should apply it in both cases.
The free in-browser dependency scan at gold.safeguard.sh/scan can show whether a project you maintain pulls in an affected package, and the Gold vulnerability directory keeps the record for this CVE.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is a login required to exploit CVE-2026-72765?
Yes. The record says an authenticated user with permission to create or modify workflows.
Do the workarounds fix it?
No. The advisory says they are only short term mitigations. The upgrade is the fix.
Sources
Last reviewed: 19 October 2026.
