GHSA-9cmh-xcqm-5hqr: n8n shared module cache

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?

1) Upgrade to n8n 1.123.67, 2.31.5, 2.32.1, or later — this is the only full remediation. 2) If immediate upgrade isn't possible, restrict the instance to fully trusted users only, since the flaw requires an authenticated Code-node-capable user. 3) Unset `NODE_FUNCTION_ALLOW_BUILTIN` and `NODE_FUNCTION_ALLOW_EXTERNAL` to remove the poisonable module surface (built-in/external module access) as a temporary compensating control — note this may break existing workflows that depend on those modules. 4) Where supported, switch to external runner mode with a dedicated runner per user or project so no shared module cache exists across trust boundaries. 5) Detection: audit `NODE_FUNCTION_ALLOW_BUILTIN`/`NODE_FUNCTION_ALLOW_EXTERNAL` env vars on all n8n instances, inventory which instances are genuinely multi-user, and review Code node execution logs for unexpected module-level errors or behavior changes correlated across unrelated users' workflows.

Q: What systems are affected by GHSA-9cmh-xcqm-5hqr?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration platforms, multi-tenant SaaS automation.

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

No CVSS score has been assigned yet.

CISO Take

n8n's JavaScript task runner shares a single module cache across every user's Code-node executions, so any user with permission to run a Code node can poison a cached module and corrupt or spy on other users' automations running on the same runner. This matters most for multi-tenant or shared n8n deployments where Code nodes are commonly used to glue together AI agent workflows — think LLM API calls, data transforms, or tool logic — since a malicious or compromised low-trust user can silently affect the confidentiality, integrity, or availability of a higher-trust user's workflow without ever escaping the sandbox or achieving remote code execution. There's no CVSS score, no CISA KEV listing, no public exploit, and no Nuclei template for this GHSA, so this is a design-flaw disclosure rather than an actively exploited bug, but the affected package (n8n) has 16 tracked downstream dependents and an OpenSSF Scorecard of just 6.6/10, underscoring that it isn't hardened by default. Patch to n8n 1.123.67, 2.31.5, or 2.32.1 immediately on any instance with more than one trusted user; if you can't patch yet, unset `NODE_FUNCTION_ALLOW_BUILTIN`/`NODE_FUNCTION_ALLOW_EXTERNAL` or move to per-user/per-project external runners as a stopgap, and treat any instance currently allowing untrusted users to run Code nodes as compromised-by-design until upgraded.

Sources: GitHub Advisory CISA KEV OpenSSF ATLAS

What is the risk?

Medium risk overall: this is a logic/isolation flaw (CWE-20, improper input validation of shared runtime state), not a sandbox escape or RCE, so it cannot be used by an external, unauthenticated attacker. It requires the attacker to already hold a legitimate account with Code-node execution rights on a multi-user n8n instance — a realistic condition for any shared/self-hosted or SaaS-style n8n deployment used by multiple teams or customers on one runner. No CVSS vector, EPSS score, CISA KEV listing, public PoC, or Nuclei template exist, so opportunistic mass exploitation is unlikely; the real risk is targeted abuse in multi-tenant automation platforms where trust boundaries between users matter (e.g., MSPs or internal shared-services teams running n8n for multiple business units). The downstream footprint (16 tracked dependents) and mediocre OpenSSF Scorecard (6.6/10) suggest the ecosystem trust in n8n's security posture is only moderate, reinforcing the need to patch rather than rely on obscurity.

How does the attack unfold?

Legitimate Access

Attacker obtains or already holds a valid user account with Code-node execution rights on a shared, multi-user n8n instance.

AML.T0012

Module Cache Poisoning

Attacker's Code node imports a built-in or external module and monkey-patches its exported function/object, which n8n's JS task runner caches for reuse.

AML.T0110

Cross-Tenant Propagation

Another user's Code-node workflow, potentially part of an AI agent automation, imports the same cached module and unknowingly executes the attacker's tampered logic.

Impact

The victim's workflow suffers data leakage, altered behavior, or a crash, breaking confidentiality, integrity, or availability without any sandbox escape or host compromise.

Legitimate Access

Attacker obtains or already holds a valid user account with Code-node execution rights on a shared, multi-user n8n instance.

AML.T0012

Module Cache Poisoning

Attacker's Code node imports a built-in or external module and monkey-patches its exported function/object, which n8n's JS task runner caches for reuse.

AML.T0110

Cross-Tenant Propagation

Another user's Code-node workflow, potentially part of an AI agent automation, imports the same cached module and unknowingly executes the attacker's tampered logic.

Impact

The victim's workflow suffers data leakage, altered behavior, or a crash, breaking confidentiality, integrity, or availability without any sandbox escape or host compromise.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.67	`1.123.67`
206.1K OpenSSF 6.7 Pushed 5d ago 53% patched ~5d 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

Moderate

What should I do?

1 step

1) Upgrade to n8n 1.123.67, 2.31.5, 2.32.1, or later — this is the only full remediation. 2) If immediate upgrade isn't possible, restrict the instance to fully trusted users only, since the flaw requires an authenticated Code-node-capable user. 3) Unset NODE_FUNCTION_ALLOW_BUILTIN and NODE_FUNCTION_ALLOW_EXTERNAL to remove the poisonable module surface (built-in/external module access) as a temporary compensating control — note this may break existing workflows that depend on those modules. 4) Where supported, switch to external runner mode with a dedicated runner per user or project so no shared module cache exists across trust boundaries. 5) Detection: audit NODE_FUNCTION_ALLOW_BUILTIN/NODE_FUNCTION_ALLOW_EXTERNAL env vars on all n8n instances, inventory which instances are genuinely multi-user, and review Code node execution logs for unexpected module-level errors or behavior changes correlated across unrelated users' workflows.

How is it classified?

Code Execution Privacy Violation Agent Plugin AML.T0110 - AI Agent Tool Poisoning

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.8 - AI system operation and monitoring

NIST AI RMF

MANAGE-2.1 - Manage risks from third-party and multi-tenant AI system components

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

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

n8n's JavaScript task runner shares a single module cache across every user's Code-node executions, so any user with permission to run a Code node can poison a cached module and corrupt or spy on other users' automations running on the same runner. This matters most for multi-tenant or shared n8n deployments where Code nodes are commonly used to glue together AI agent workflows — think LLM API calls, data transforms, or tool logic — since a malicious or compromised low-trust user can silently affect the confidentiality, integrity, or availability of a higher-trust user's workflow without ever escaping the sandbox or achieving remote code execution. There's no CVSS score, no CISA KEV listing, no public exploit, and no Nuclei template for this GHSA, so this is a design-flaw disclosure rather than an actively exploited bug, but the affected package (n8n) has 16 tracked downstream dependents and an OpenSSF Scorecard of just 6.6/10, underscoring that it isn't hardened by default. Patch to n8n 1.123.67, 2.31.5, or 2.32.1 immediately on any instance with more than one trusted user; if you can't patch yet, unset `NODE_FUNCTION_ALLOW_BUILTIN`/`NODE_FUNCTION_ALLOW_EXTERNAL` or move to per-user/per-project external runners as a stopgap, and treat any instance currently allowing untrusted users to run Code nodes as compromised-by-design until upgraded.

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?

1) Upgrade to n8n 1.123.67, 2.31.5, 2.32.1, or later — this is the only full remediation. 2) If immediate upgrade isn't possible, restrict the instance to fully trusted users only, since the flaw requires an authenticated Code-node-capable user. 3) Unset `NODE_FUNCTION_ALLOW_BUILTIN` and `NODE_FUNCTION_ALLOW_EXTERNAL` to remove the poisonable module surface (built-in/external module access) as a temporary compensating control — note this may break existing workflows that depend on those modules. 4) Where supported, switch to external runner mode with a dedicated runner per user or project so no shared module cache exists across trust boundaries. 5) Detection: audit `NODE_FUNCTION_ALLOW_BUILTIN`/`NODE_FUNCTION_ALLOW_EXTERNAL` env vars on all n8n instances, inventory which instances are genuinely multi-user, and review Code node execution logs for unexpected module-level errors or behavior changes correlated across unrelated users' workflows.

What systems are affected by GHSA-9cmh-xcqm-5hqr?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration platforms, multi-tenant SaaS automation.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration platformsmulti-tenant SaaS automation

MITRE ATLAS Techniques

AML.T0110 AI Agent Tool Poisoning

Compliance Controls Affected

ISO 42001: A.6.2.8

NIST AI RMF: MANAGE-2.1

OWASP LLM Top 10: LLM07

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.

Exploitation Scenario

A malicious or compromised user with legitimate but limited access to a shared, multi-tenant n8n instance (common in MSP setups or internal shared-automation platforms) creates a workflow with a Code node that imports a commonly used built-in or external Node.js module and monkey-patches one of its exported functions or objects — for example, altering a JSON parser, an HTTP client wrapper, or a utility module frequently used in AI agent tool logic. Because the JS task runner caches modules once loaded and reuses that cache across all users' Code-node executions on the runner, the next time any other user's workflow (potentially an AI agent automation calling an LLM API or processing RAG data) triggers a Code node that imports the same module, it silently executes the attacker's tampered version instead of the original. Depending on what the attacker altered, this can leak that other user's data back to the attacker, corrupt the logic/output of their AI agent workflow, or cause it to fail — all while the attacker never leaves the JS sandbox or touches the underlying host.

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.