Understanding the n8n Module Cache Poisoning Vulnerability
A significant security flaw, identified as CVE-2026-72764, has been discovered in n8n, a popular workflow automation tool. This vulnerability impacts multi-user n8n instances, specifically those running its JavaScript task runner with built-in or external modules enabled. In simple terms, this flaw could allow one user to tamper with the system processes of other users on the same n8n server.
The problem stems from how n8n’s JavaScript task runner managed its module cache. This cache was shared across all users when executing “Code” nodes. An attacker, with the ability to run a Code node, could “poison” this shared cache. This means they could insert malicious code into the cache. When other users then execute their own Code nodes, the poisoned cache could alter their operations. This could compromise their data privacy (confidentiality), the accuracy of their data (integrity), or even interrupt their ability to use the system (availability).
It’s important to note that this is a “cross-user isolation break.” It means users on the same n8n instance can affect each other. However, it is not a “sandbox escape” or “remote code execution.” This means an attacker cannot break out of the n8n environment to control the underlying server or execute arbitrary code directly on it.
CVE Details
- Product: n8n (specifically for Node.js environments)
- Published Date: August 11, 2026
- Severity: HIGH
- Status: Analyzed
Affected Products
The n8n vulnerability (CVE-2026-72764) affects versions of n8n prior to:
- 1.123.67
- 2.31.5
- 2.32.1
For example, version 2.32.0 is known to be vulnerable.
Current Status
This vulnerability has been thoroughly analyzed. Details regarding its impact and potential solutions are available to help users protect their systems.
Severity Level
The Common Vulnerability Scoring System (CVSS) rates CVE-2026-72764 with a score of 8.8, classifying it as HIGH severity. This rating indicates that while an attacker needs some level of access (low privileges) and specific conditions (presence of built-in/external modules enabled) to exploit it, a successful attack could have a significant impact on other users’ data confidentiality, integrity, and the availability of their workflow executions within the n8n platform.
Possible Solutions
To secure your n8n instance against this module cache poisoning vulnerability, the primary recommendation is to update your software immediately.
Patches:
Upgrade your n8n installation to one of the following patched versions or newer:
- n8n version 1.123.67 or later
- n8n version 2.31.5 or later
- n8n version 2.32.1 or later
Workarounds (Temporary Mitigations):
If an immediate upgrade isn’t feasible, consider these temporary steps to reduce risk. Please remember these are not full solutions and should be implemented only until you can apply the official patches:
- Restrict User Access: Limit access to your n8n instance only to users you fully trust.
- Disable Module Access in Code Nodes: Prevent Code nodes from accessing built-in or external modules. You can do this by unsetting the environment variables
NODE_FUNCTION_ALLOW_BUILTINandNODE_FUNCTION_ALLOW_EXTERNAL. This removes the vulnerable surface area. - Utilize External Runner Mode: If your deployment setup supports it, consider running n8n in external runner mode. Configure this mode to use a dedicated runner for each user or project, which helps isolate their Code-node executions.
These workarounds are designed for short-term protection. Prioritize applying the official patches as soon as possible for complete remediation.
References
https://github.com/n8n-io/n8n/security/advisories/GHSA-9cmh-xcqm-5hqr
https://www.vulncheck.com/advisories/n8n-before-module-cache-poisoning-via-code-node
