CVE-2026-72764: n8n module cache poisoning breaks

CISO Take

n8n's external JavaScript task runner shares a single module cache across every user's Code-node executions on the same runner, so one authenticated user can poison a cached module and tamper with the confidentiality, integrity, or availability of another tenant's workflow runs on the same instance. This matters mainly for organizations running multi-user or multi-tenant self-hosted n8n with the JS task runner and built-in or external modules enabled, since n8n increasingly orchestrates AI agent and LLM pipelines where a poisoned module could silently alter an API call, leak data between tenants, or crash a shared workflow. The vendor frames this as a cross-user isolation break, not a sandbox escape or RCE; CISA's SSVC decision is the lowest actionable tier (TRACK), EPSS is just 0.00374 (69th percentile — low priority), it is not in CISA KEV, and there is no public exploit or Nuclei template, so urgency is moderate rather than critical. Patch to n8n 1.123.67, 2.31.5, or 2.32.1; until then, treat any multi-user n8n deployment on the JS task runner as needing per-tenant runner isolation or restricted module access, and audit who currently has Code-node execution rights on shared instances.

Sources: NVD EPSS CISA KEV GitHub Advisory vulncheck.com

What is the risk?

No CVSS score is published and the vector is unscored, but the bug requires an existing authenticated account with Code-node execution rights on a shared, multi-user n8n instance — it is not remotely exploitable by an anonymous attacker and is explicitly not a sandbox escape or RCE. Real-world risk is bounded to environments that (a) run multiple users on one n8n instance, (b) use the external JS task runner, and (c) enable built-in or external modules for Code nodes; single-tenant or per-user-isolated deployments are unaffected. Exploitation likelihood signals are all low: EPSS 0.00374 (69th percentile), no CISA KEV listing, no public PoC, no Nuclei template, and CISA's own SSVC verdict is TRACK, the lowest triage bucket. Net assessment: low-to-moderate risk, worth patching on the normal cycle rather than as an emergency, but relevant to flag in any compliance review of shared automation infrastructure.

How does the attack unfold?

Initial access

Attacker holds a legitimate, limited account with Code-node authoring/execution rights on a shared multi-user n8n instance.

AML.T0012

Cache poisoning

Attacker's Code node overwrites or tampers with a module in the JS task runner's shared cache, which is not isolated per user.

Cross-tenant propagation

A different user's Code-node execution (e.g., part of an AI agent workflow) subsequently requires the same module and unknowingly runs the poisoned version.

AML.T0011.002

Impact

Victim's workflow output, data handling, or availability is compromised without the attacker ever accessing the victim's workflow directly.

Initial access

Attacker holds a legitimate, limited account with Code-node authoring/execution rights on a shared multi-user n8n instance.

AML.T0012

Cache poisoning

Attacker's Code node overwrites or tampers with a module in the JS task runner's shared cache, which is not isolated per user.

Cross-tenant propagation

A different user's Code-node execution (e.g., part of an AI agent workflow) subsequently requires the same module and unknowingly runs the poisoned version.

AML.T0011.002

Impact

Victim's workflow output, data handling, or availability is compromised without the attacker ever accessing the victim's workflow directly.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	—	No patch
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

0.8%

chance of exploitation in 30 days

Higher than 55% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade n8n to 1.123.67 (1.x line) or 2.31.5 / 2.32.1 (2.x line), which fix the shared module cache. Until patched, avoid running multiple mutually-untrusted users against a single JS task runner instance — isolate task runners per tenant/team, or disable built-in and external module access for Code nodes in shared instances to shrink the poisonable surface. For detection, audit task runner logs and Code-node execution history for anomalous or unexpected module usage patterns across different users' workflows, and review which accounts currently have Code-node authoring/execution privileges on shared instances.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code Execution Data Leakage DoS Agent Framework AML.T0011.002 - Poisoned AI Agent Tool

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

Frequently Asked Questions

What is CVE-2026-72764?

n8n's external JavaScript task runner shares a single module cache across every user's Code-node executions on the same runner, so one authenticated user can poison a cached module and tamper with the confidentiality, integrity, or availability of another tenant's workflow runs on the same instance. This matters mainly for organizations running multi-user or multi-tenant self-hosted n8n with the JS task runner and built-in or external modules enabled, since n8n increasingly orchestrates AI agent and LLM pipelines where a poisoned module could silently alter an API call, leak data between tenants, or crash a shared workflow. The vendor frames this as a cross-user isolation break, not a sandbox escape or RCE; CISA's SSVC decision is the lowest actionable tier (TRACK), EPSS is just 0.00374 (69th percentile — low priority), it is not in CISA KEV, and there is no public exploit or Nuclei template, so urgency is moderate rather than critical. Patch to n8n 1.123.67, 2.31.5, or 2.32.1; until then, treat any multi-user n8n deployment on the JS task runner as needing per-tenant runner isolation or restricted module access, and audit who currently has Code-node execution rights on shared instances.

Is CVE-2026-72764 actively exploited?

No confirmed active exploitation of CVE-2026-72764 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-72764?

Upgrade n8n to 1.123.67 (1.x line) or 2.31.5 / 2.32.1 (2.x line), which fix the shared module cache. Until patched, avoid running multiple mutually-untrusted users against a single JS task runner instance — isolate task runners per tenant/team, or disable built-in and external module access for Code nodes in shared instances to shrink the poisonable surface. For detection, audit task runner logs and Code-node execution history for anomalous or unexpected module usage patterns across different users' workflows, and review which accounts currently have Code-node authoring/execution privileges on shared instances.

What systems are affected by CVE-2026-72764?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration pipelines.

What is the CVSS score for CVE-2026-72764?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration pipelines

MITRE ATLAS Techniques

AML.T0011.002 Poisoned AI Agent Tool

Compliance Controls Affected

EU AI Act: Article 15

What are the technical details?

Original Advisory

n8n's JavaScript task runner shared a single module cache across all users' Code-node executions. In affected versions (before 1.123.67, 2.31.5, and 2.32.1), a user able to run a Code node could poison a cached module and thereby 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 and does not constitute a sandbox escape or remote code execution. Only multi-user instances running the JS task runner with built-in or external modules enabled are affected.

Exploitation Scenario

An attacker with a legitimate but limited account on a shared, multi-tenant n8n instance (e.g., an internal automation platform or n8n-cloud-style shared deployment) authors a workflow with a Code node that monkey-patches or overwrites a commonly-imported module in the shared runner's module cache. When another tenant's workflow later executes a Code node that requires the same module — for instance, a Code node in an AI agent workflow that calls an LLM API or handles credentials — it unknowingly runs the attacker's tampered logic instead of the legitimate module. This lets the attacker corrupt that victim workflow's output, exfiltrate data flowing through it, or crash its execution, entirely without ever having direct access to the victim's workflow definition or credentials.

Weaknesses (CWE)

CWE-668 Exposure of Resource to Wrong Sphere Primary CWE-668 Exposure of Resource to Wrong Sphere

CWE-668 — Exposure of Resource to Wrong Sphere: The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.

Source: MITRE CWE corpus.