GHSA-9cmh-xcqm-5hqr: n8n: Cross-Tenant Module-Cache Poisoning in the JS Task Runner

The JS task runner executes Code nodes. Before the fix it shared a single module cache across every user's executions. A user who can run a Code node can load a built-in or external module, change it in memory (for example by overwriting a function on its exports), and leave the altered module in the cache. A later Code node from another user on the same runner then loads the altered module instead of the real one.

The poisoned module can read data that the victim's code passes into it, change what it returns, or make it fail. That affects the victim's confidentiality, integrity or availability. The advisory is explicit that this is not a sandbox escape or remote code execution. It breaks isolation between users of one instance.

All multi-user instances that run the JS task runner with built-in or external modules enabled are affected. The attacker needs a low-privilege account that can run Code nodes. Single-user instances gain nothing from the attack, since there is no one else to poison.

The npm package n8n below 1.123.67 on the 1.x line, >= 2.0.0-rc.0, < 2.31.5, and 2.32.0. Exposure needs several users on one instance, the JS task runner, and built-in or external module access in Code nodes.

npm ls n8n

Check whether NODE_FUNCTION_ALLOW_BUILTIN or NODE_FUNCTION_ALLOW_EXTERNAL is set in your environment. If neither is set, the poisonable module surface is already removed.

Upgrade n8n to 1.123.67, 2.31.5 or 2.32.1, or later, matching your release line.

Temporary measures from the advisory, which it says do not fully remove the risk:

• Limit instance access to fully trusted users.
• Unset NODE_FUNCTION_ALLOW_BUILTIN and NODE_FUNCTION_ALLOW_EXTERNAL to turn off module access in Code nodes.
• Where supported, use the external runner mode with a dedicated runner for each user or project.

Restart the task runner after changing settings so a poisoned cache is dropped.

The advisory gives no log signature. Restarting the task runner clears any poisoned cache, so do that after upgrading. Look at Code nodes written by users who should not need modules, particularly ones that import built-in or external modules and reassign their properties or prototypes. Compare execution outputs of other users' Code nodes for unexpected results, errors or timing changes that began after another user's runs.

If you cannot tell, treat data processed by shared runners as possibly affected.

Impact

n8n's JavaScript task runner shared one module cache across all users' Code-node executions, so a user able to run a Code node could poison a cached module and alter other users' Code-node executions on the same runner, affecting their confidentiality, integrity, or availability.

This is a cross-user isolation break within a single n8n instance. It does not constitute a sandbox escape or remote code execution. All multi-user n8n instances running the JS task runner with built-in or external modules enabled are affected.

Patches

The issue has been fixed 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.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations:

• Restrict n8n instance access to fully trusted users only.
• Disable built-in and external module access in Code nodes by unsetting NODE_FUNCTION_ALLOW_BUILTIN and NODE_FUNCTION_ALLOW_EXTERNAL, which removes the poisonable module surface.
• Use the external runner mode with a dedicated runner per user or project if your deployment supports it.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.