CVE-2026-86076: n8n expression sandbox escape enables

Q: Is CVE-2026-86076 actively exploited?

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

Q: How to fix CVE-2026-86076?

Upgrade immediately to n8n 1.123.76, 2.37.7, or 2.38.2, which fix the PrototypeSanitizer AST hook in packages/workflow/src/expression-sandboxing.ts. Until patched, restrict who can create, edit, or import workflows (treat workflow-authoring rights as equivalent to code-execution rights), disable or tightly gate community/shared workflow templates, and avoid exposing the editor to untrusted or external users. Post-patch, audit workflow execution logs and version history for expressions containing suspicious class field names (especially '__sanitize' or other double-underscore reserved-looking identifiers) that may indicate pre-patch exploitation attempts, and rotate any credentials stored in n8n if compromise is suspected.

Q: What systems are affected by CVE-2026-86076?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration pipelines, low-code AI automation platforms.

Q: What is the CVSS score for CVE-2026-86076?

No CVSS score has been assigned yet.

CISO Take

A flaw in n8n's expression compiler lets a workflow author define a class field named __sanitize that hijacks the dynamically-scoped 'this' binding used by the PrototypeSanitizer, reaching the JavaScript Function constructor and escaping the intended expression sandbox to run arbitrary code on the backend and in the editor preview. n8n is a widely deployed low-code automation platform increasingly used to orchestrate AI agents and LLM tool chains, so any tenant or user who can author or import a workflow — a routine, low-privilege action in most n8n deployments — can pivot straight to full backend compromise, exposing every credential, API key, and connected system stored in the instance. There is no CISA KEV listing, no published EPSS score, and no known public exploit or Nuclei template yet, so this is not currently being mass-exploited, but the technique is trivial to reproduce once understood and the classification as CWE-94 code injection with 'high' severity plus a public GHSA advisory means a working PoC is likely to surface quickly. Patch immediately to n8n 1.123.76, 2.37.7, or 2.38.2; until patched, restrict workflow creation/import to trusted users and treat any n8n instance exposed to untrusted workflow authors (community templates, shared/multi-tenant instances, self-service AI-agent builders) as high risk.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

High risk despite the absence of KEV listing, EPSS data, or public exploit code. The vulnerability is a sandbox-escape / code-injection flaw (CWE-94) in a core AST hook (PrototypeSanitizer) of the expression evaluator, meaning any user able to define or edit a workflow expression — a normal capability for workflow authors, not an administrative one — can achieve arbitrary JavaScript execution on the n8n backend and in editor previews. The barrier to exploitation is understanding of the sanitizer's internal 'this' binding logic rather than any special network position or privileged account, which raises real-world exploitability once the technique is public (it already is, via the GHSA advisory). No downstream dependent or Scorecard data is available, but n8n's role as a widely adopted AI agent/workflow orchestration hub for connecting LLMs to internal systems significantly amplifies blast radius.

How does the attack unfold?

Initial Access

Attacker with workflow-authoring privileges (or via an imported/shared malicious workflow template) crafts an expression defining a class field named __sanitize.

AML.T0011

Sandbox Bypass

The expression compiler's dynamically-scoped 'this' binding lets the reserved-looking field rebind the PrototypeSanitizer instead of rejecting it.

Code Execution

The rebound sanitizer reaches the JavaScript Function constructor, allowing arbitrary code execution on the n8n backend and in the editor preview.

AML.T0053

Impact

Arbitrary backend code execution exposes all credentials and connected systems managed by the n8n instance, enabling data theft and lateral movement.

Initial Access

Attacker with workflow-authoring privileges (or via an imported/shared malicious workflow template) crafts an expression defining a class field named __sanitize.

AML.T0011

Sandbox Bypass

The expression compiler's dynamically-scoped 'this' binding lets the reserved-looking field rebind the PrototypeSanitizer instead of rejecting it.

Code Execution

The rebound sanitizer reaches the JavaScript Function constructor, allowing arbitrary code execution on the n8n backend and in the editor preview.

AML.T0053

Impact

Arbitrary backend code execution exposes all credentials and connected systems managed by the n8n instance, enabling data theft and lateral movement.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.76	`1.123.76`
204.1K OpenSSF 6.6 16 dependents Pushed 7d 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.4%

chance of exploitation in 30 days

Higher than 37% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Advanced

What should I do?

1 step

Upgrade immediately to n8n 1.123.76, 2.37.7, or 2.38.2, which fix the PrototypeSanitizer AST hook in packages/workflow/src/expression-sandboxing.ts. Until patched, restrict who can create, edit, or import workflows (treat workflow-authoring rights as equivalent to code-execution rights), disable or tightly gate community/shared workflow templates, and avoid exposing the editor to untrusted or external users. Post-patch, audit workflow execution logs and version history for expressions containing suspicious class field names (especially '__sanitize' or other double-underscore reserved-looking identifiers) that may indicate pre-patch exploitation attempts, and rotate any credentials stored in n8n if compromise is suspected.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

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

How is it classified?

Code Execution Framework Agent AML.T0053 - AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - Security controls for AI system components

NIST AI RMF

MEASURE 2.7 - AI system security and resilience is evaluated and documented

OWASP LLM Top 10

LLM07 - Insecure Plugin/Tool Design

Frequently Asked Questions

What is CVE-2026-86076?

A flaw in n8n's expression compiler lets a workflow author define a class field named __sanitize that hijacks the dynamically-scoped 'this' binding used by the PrototypeSanitizer, reaching the JavaScript Function constructor and escaping the intended expression sandbox to run arbitrary code on the backend and in the editor preview. n8n is a widely deployed low-code automation platform increasingly used to orchestrate AI agents and LLM tool chains, so any tenant or user who can author or import a workflow — a routine, low-privilege action in most n8n deployments — can pivot straight to full backend compromise, exposing every credential, API key, and connected system stored in the instance. There is no CISA KEV listing, no published EPSS score, and no known public exploit or Nuclei template yet, so this is not currently being mass-exploited, but the technique is trivial to reproduce once understood and the classification as CWE-94 code injection with 'high' severity plus a public GHSA advisory means a working PoC is likely to surface quickly. Patch immediately to n8n 1.123.76, 2.37.7, or 2.38.2; until patched, restrict workflow creation/import to trusted users and treat any n8n instance exposed to untrusted workflow authors (community templates, shared/multi-tenant instances, self-service AI-agent builders) as high risk.

Is CVE-2026-86076 actively exploited?

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

How to fix CVE-2026-86076?

Upgrade immediately to n8n 1.123.76, 2.37.7, or 2.38.2, which fix the PrototypeSanitizer AST hook in packages/workflow/src/expression-sandboxing.ts. Until patched, restrict who can create, edit, or import workflows (treat workflow-authoring rights as equivalent to code-execution rights), disable or tightly gate community/shared workflow templates, and avoid exposing the editor to untrusted or external users. Post-patch, audit workflow execution logs and version history for expressions containing suspicious class field names (especially '__sanitize' or other double-underscore reserved-looking identifiers) that may indicate pre-patch exploitation attempts, and rotate any credentials stored in n8n if compromise is suspected.

What systems are affected by CVE-2026-86076?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration pipelines, low-code AI automation platforms.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration pipelineslow-code AI automation platforms

MITRE ATLAS Techniques

AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

n8n is an open source workflow automation platform. Prior to 1.123.76, 2.37.7, and 2.38.2, the expression compiler sanitizer resolved through dynamically scoped this and did not reject reserved class member names. A class field named __sanitize could rebind the sanitizer and reach the Function constructor, enabling backend code execution and editor-preview JavaScript execution. The affected AST hook is PrototypeSanitizer in packages/workflow/src/expression-sandboxing.ts. This issue is fixed in versions 1.123.76, 2.37.7 and 2.38.2.

Exploitation Scenario

An attacker who holds (or gains, e.g. via a shared/multi-tenant instance or a malicious imported workflow template) low-privilege workflow-editor access crafts an n8n expression containing a class with a field named __sanitize. When the expression compiler evaluates this construct, the dynamically-scoped 'this' reference lets the attacker's field rebind the PrototypeSanitizer itself instead of being rejected as a reserved name, giving the attacker's code a path to the native Function constructor. Invoking that constructor breaks out of the intended sandbox, executing arbitrary JavaScript in the backend workflow-execution context (and in the editor preview pane before the workflow is even run), from which the attacker can read environment secrets, call out to external infrastructure, or manipulate other workflows/agents running on the same n8n instance.

Weaknesses (CWE)

CWE-94 Improper Control of Generation of Code ('Code Injection') Primary CWE-94 Improper Control of Generation of Code ('Code Injection') Primary CWE-94 Improper Control of Generation of Code ('Code Injection')

CWE-94 — Improper Control of Generation of Code ('Code Injection'): The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

[Architecture and Design] Refactor your program so that you do not have to dynamically generate code.
[Architecture and Design] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.