CVE-2026-72764: High Module Cache Poisoning in n8n

CVE-2026-72764 is a cross-user isolation flaw in the n8n JavaScript task runner. All Code nodes shared one module cache, so one user could alter what other users' Code nodes run. The record scores it 8.8, High. Upgrade to n8n 1.123.67, 2.31.5 or 2.32.1, or restrict who can run Code nodes.

What's affected

The advisory lists affected versions as anything before 1.123.67 on the 1.x line, before 2.31.5 on the 2.31 line, and before 2.32.1 on the 2.32 line. The patched releases are 1.123.67, 2.31.5 and 2.32.1.

Not every install is exposed. The record and the advisory both say only multi-user instances that run the JavaScript task runner with built-in or external modules enabled are affected. A single-user instance, or one where Code node module access is switched off, does not match that description. The advisory also states plainly that this is a cross-user isolation break inside one instance. It is not a sandbox escape and it is not remote code execution.

The weakness class is CWE-668, exposure of a resource to the wrong sphere. The shared cache is the resource, and every user of the runner shares it.

How to check if you're exposed

Find the version of every n8n instance you run, including containers and any copy bundled in another product.

n8n --version
docker exec <container-name> n8n --version
npm ls n8n

If the version is below the patched release for your line, you are in the affected range. Remember that n8n often runs as a base image tag in Docker or Kubernetes, so check image tags in your manifests as well as running hosts. A dependency scan of the repository that holds your deployment files will surface pinned n8n packages. The free in-browser scan at gold.safeguard.sh/scan accepts a manifest and lists known CVEs for what it finds.

Then check whether the exposed feature is in use. The advisory names two environment variables that control module access in Code nodes.

env | grep -E 'NODE_FUNCTION_ALLOW_(BUILTIN|EXTERNAL)'

If neither variable is set, the poisonable module surface the advisory describes is not enabled. If either is set and more than one person can create or run Code nodes, treat the instance as exposed until it is upgraded.

What to do now

1. Upgrade n8n to 1.123.67, 2.31.5 or 2.32.1 or later, whichever matches your release line.
2. If you cannot upgrade today, limit instance access to fully trusted users only.
3. As a short term measure, unset NODE_FUNCTION_ALLOW_BUILTIN and NODE_FUNCTION_ALLOW_EXTERNAL so Code nodes lose built-in and external modules. The advisory notes this removes the poisonable module surface.
4. If your deployment supports external runner mode, use a dedicated runner per user or project.
5. Review which workflows depend on modules in Code nodes before you change those variables, because removing them will break workflows that import packages.
6. Record the upgrade in your change log and recheck the version after rollout.

Why it matters

Multi-user automation platforms promise that one user's work does not touch another's. A shared module cache breaks that promise quietly. If user A can change what a cached module does, then user B's next Code node run executes code that A shaped, and B has no way to tell.

The severity needs care. The record scores this 8.8 High under CVSS 3.1. The GitHub advisory labels it Moderate with a CVSS 4.0 score of 5.8, and VulnCheck lists medium at 5.8. Both views agree on the facts. They differ on how to weigh them, mostly because the real impact depends on who your users are. On an instance where every user is trusted, the risk is small. On an instance shared between teams or customers, treat it as the higher rating. Nothing in the record or the advisory says it has been exploited in the wild, and it is not on the CISA KEV list.

Try it yourself

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

Quick check

Sources

• GitHub security advisory for the n8n project
• VulnCheck advisory

Last reviewed: 18 October 2026.