GHSA-9cmh-xcqm-5hqr: n8n — MEDIUM

Q: Is GHSA-9cmh-xcqm-5hqr actively exploited?

No confirmed active exploitation of GHSA-9cmh-xcqm-5hqr has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-9cmh-xcqm-5hqr?

Update to patched version: n8n 1.123.67.

Q: What is the CVSS score for GHSA-9cmh-xcqm-5hqr?

No CVSS score has been assigned yet.

## 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...

Full CISO analysis pending enrichment.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.67	`1.123.67`
197.0K OpenSSF 6.6 16 dependents Pushed 4d ago 61% patched ~6d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

N/A

What should I do?

Patch available

Update n8n to version 1.123.67

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is GHSA-9cmh-xcqm-5hqr?

## 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.

Is GHSA-9cmh-xcqm-5hqr actively exploited?

No confirmed active exploitation of GHSA-9cmh-xcqm-5hqr has been reported, but organizations should still patch proactively.

How to fix GHSA-9cmh-xcqm-5hqr?

Update to patched version: n8n 1.123.67.

What is the CVSS score for GHSA-9cmh-xcqm-5hqr?

No CVSS score has been assigned yet.

What are the technical details?

Original Advisory

## 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.

Weaknesses (CWE)

CWE-20 Improper Input Validation Primary

CWE-20 — Improper Input Validation: The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

[Architecture and Design] Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
[Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Source: MITRE CWE corpus.