The vulnerability in n8n involves the JavaScript task runner sharing a single module cache among all users' Code-node executions. A user with the ability to run a Code node can poison this shared module cache, causing other users' Code-node executions on the same runner to be altered. This results in a cross-user isolation break within the same n8n instance, impacting confidentiality, integrity, or availability of Code-node executions. The vulnerability does not allow sandbox escape or remote code execution. It affects all multi-user n8n instances using the JS task runner with built-in or external modules enabled. The issue has been officially fixed in versions 1.123.67, 2.31.5, and 2.32.1. Temporary mitigations include restricting instance access to trusted users, disabling built-in and external module access in Code nodes by unsetting specific environment variables, and using external runner mode with dedicated runners per user or project.

This vulnerability allows a user to poison the shared module cache in the JavaScript task runner, causing other users' Code-node executions to be altered. This breaks user isolation within a single n8n instance and can affect the confidentiality, integrity, or availability of other users' Code-node executions. However, it does not enable sandbox escape or remote code execution.

A fix is available in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading immediately is not possible, administrators should restrict n8n instance access to fully trusted users, disable built-in and external module access in Code nodes by unsetting NODE_FUNCTION_ALLOW_BUILTIN and NODE_FUNCTION_ALLOW_EXTERNAL environment variables, and consider using the external runner mode with a dedicated runner per user or project. These workarounds do not fully remediate the risk and should only be used as short-term mitigations.