CVE-2026-77077: n8n: EventEmitter prototype pollution enables sandbox RCE

HIGH
Published August 20, 2026
CISO Take

n8n's JavaScript task runner sandbox has a gap in its prototype-freezing logic — it locks down globalThis functions but misses internal module constructors like EventEmitter, so an authenticated user with Code node access can pollute the prototype chain and execute arbitrary commands inside the runner container. This matters because n8n is a widely deployed AI agent orchestration platform (16 downstream dependents in our tracking) and, critically, the corrupted prototype is process-wide: on shared multi-tenant runners, one tenant's exploit can taint Code node executions belonging to other tenants running on the same infrastructure. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so this isn't under active mass exploitation — but the vendor GitHub Security Advisory (GHSA-m3hg-p5r9-fg9h) and VulnCheck both rate it high severity, and on v1.x deployments without task runners enabled the impact is worse because Code node JS runs directly in the main n8n process. Patch immediately to 1.123.69 (v1.x), 2.33.4, or 2.34.1 (v2.x), and if you operate n8n as a multi-tenant service, treat any pre-patch Code node execution as a potential cross-tenant compromise indicator until logs are reviewed.

Sources:NVDGitHub AdvisoryVulnCheckOpenSSFATLAS

What is the risk?

Exploitability requires an authenticated account with Code node permissions — this is not an unauthenticated, internet-facing bug — but the barrier to entry is low in typical n8n deployments where many workflow authors have Code node access by default. Exploitation demands working knowledge of JavaScript prototype pollution and Node.js internals (EventEmitter constructor abuse), placing it above trivial script-kiddie exploitation but well within reach of any competent web attacker; no novel research is needed since prototype pollution is a well-documented class of bug (CWE-94, listed twice, underscoring the code-injection nature). Impact is severe: arbitrary command execution within the runner container, with process-wide persistence meaning a single malicious or compromised tenant can corrupt code execution for every other tenant sharing that runner. The package carries an OpenSSF Scorecard of 6.6/10 and an internal package risk score of 69/100, with 201 other CVEs recorded against n8n historically — indicating a track record of security issues that compounds the operational risk of running it as shared multi-tenant infrastructure, especially where it orchestrates AI agent workflows with access to LLM API keys, vector DB credentials, or other sensitive integrations.

How does the attack unfold?

Initial Access
Attacker obtains or already holds an authenticated n8n account with Code node access, typically as a lower-privileged workflow author or tenant in a shared instance.
AML.T0012
Sandbox Exploitation
Attacker writes JavaScript in a Code node that manipulates the EventEmitter module's constructor prototype, a path not covered by the runner's prototype-freezing routine.
AML.T0050
Defense Evasion / Escape
The prototype pollution corrupts a process-wide object, allowing the payload to bypass sandbox restrictions and execute arbitrary OS commands within the runner container.
AML.T0107
Cross-Tenant Impact
Because the corruption is process-wide and persists, it taints subsequent Code node executions from other tenants sharing the same runner, extending compromise beyond the initial attacker's own workflow.
AML.T0105

What systems are affected?

PackageEcosystemVulnerable RangePatched
n8nnpm—No patch
209.2KOpenSSF 7.116 dependentsPushed today44% patched~19d to patchFull package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.6%
chance of exploitation in 30 days
Higher than 47% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Advanced

What should I do?

1 step
  1. Patch immediately to n8n 1.123.69 (v1.x line) or 2.33.4 / 2.34.1 (v2.x line) — this is the only complete fix since it addresses the prototype-freezing gap directly. Until patched: restrict Code node access to trusted, vetted users only via n8n's role-based permissions, avoid running untrusted or multi-tenant workflows on shared task runners, and where possible move to per-tenant isolated runner containers rather than a shared pool. Detection guidance: audit Code node execution logs for JavaScript referencing EventEmitter, Object.prototype, __proto__, constructor.prototype, or other prototype-pollution idioms; monitor runner containers for anomalous child process spawning or unexpected outbound network connections; and treat any pre-patch runner as potentially compromised if it processed Code node executions from untrusted or lower-trust tenants — rotate credentials accessible to that runner as a precaution.

What does CISA's SSVC say?

DecisionTrack
Exploitationnone
AutomatableNo
Technical Impactpartial

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

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15-Accuracy, robustness and cybersecurity
ISO 42001
A.6.2.2-AI system operation and monitoring
NIST AI RMF
MANAGE-2.3-Mechanisms are in place to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use
OWASP LLM Top 10
LLM08-Excessive Agency

Frequently Asked Questions

What is CVE-2026-77077?

n8n's JavaScript task runner sandbox has a gap in its prototype-freezing logic — it locks down globalThis functions but misses internal module constructors like EventEmitter, so an authenticated user with Code node access can pollute the prototype chain and execute arbitrary commands inside the runner container. This matters because n8n is a widely deployed AI agent orchestration platform (16 downstream dependents in our tracking) and, critically, the corrupted prototype is process-wide: on shared multi-tenant runners, one tenant's exploit can taint Code node executions belonging to other tenants running on the same infrastructure. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so this isn't under active mass exploitation — but the vendor GitHub Security Advisory (GHSA-m3hg-p5r9-fg9h) and VulnCheck both rate it high severity, and on v1.x deployments without task runners enabled the impact is worse because Code node JS runs directly in the main n8n process. Patch immediately to 1.123.69 (v1.x), 2.33.4, or 2.34.1 (v2.x), and if you operate n8n as a multi-tenant service, treat any pre-patch Code node execution as a potential cross-tenant compromise indicator until logs are reviewed.

Is CVE-2026-77077 actively exploited?

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

How to fix CVE-2026-77077?

Patch immediately to n8n 1.123.69 (v1.x line) or 2.33.4 / 2.34.1 (v2.x line) — this is the only complete fix since it addresses the prototype-freezing gap directly. Until patched: restrict Code node access to trusted, vetted users only via n8n's role-based permissions, avoid running untrusted or multi-tenant workflows on shared task runners, and where possible move to per-tenant isolated runner containers rather than a shared pool. Detection guidance: audit Code node execution logs for JavaScript referencing `EventEmitter`, `Object.prototype`, `__proto__`, `constructor.prototype`, or other prototype-pollution idioms; monitor runner containers for anomalous child process spawning or unexpected outbound network connections; and treat any pre-patch runner as potentially compromised if it processed Code node executions from untrusted or lower-trust tenants — rotate credentials accessible to that runner as a precaution.

What systems are affected by CVE-2026-77077?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-tenant AI workflow orchestration, shared code-execution sandboxes.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-tenant AI workflow orchestrationshared code-execution sandboxes

MITRE ATLAS Techniques

AML.T0050Command and Scripting Interpreter
AML.T0105Escape to Host
AML.T0107Exploitation for Defense Evasion

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2.2
NIST AI RMF: MANAGE-2.3
OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

n8n versions before 1.123.69, 2.33.4, and 2.34.1 contain a JavaScript task runner VM sandbox escape. The runner's prototype-freezing routine covers globalThis functions but not internal module constructors such as EventEmitter, allowing an authenticated user with Code node access to exploit prototype pollution to execute arbitrary commands within the runner container. Because the polluted prototype is a process-wide object, the corruption persists across other tenants' Code node executions on the same shared runner. On v1.x instances without task runners enabled, Code node JavaScript runs directly in the main n8n process, where the impact could be higher.

Exploitation Scenario

An attacker with a low-privilege but legitimate n8n account (e.g., a contractor or a tenant in a shared SaaS n8n instance) creates a workflow using a Code node and writes JavaScript that manipulates the EventEmitter module's constructor prototype — a path the sandbox's prototype-freezing routine fails to cover. This pollutes a process-wide object in the runner container, allowing the payload to break out of the intended JS sandbox and invoke Node.js APIs needed to spawn OS-level commands, effectively achieving remote code execution inside the runner. Because the pollution is process-wide and persists, subsequent Code node executions from other tenants sharing that same runner inherit the corrupted state, letting the attacker potentially intercept or manipulate other tenants' workflow executions, or use the initial RCE foothold to harvest credentials and pivot further into connected AI services (LLM APIs, vector stores, internal systems reachable from the runner network).

Weaknesses (CWE)

CWE-94 — Improper Control of Generation of Code: 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.

Timeline

Published
August 20, 2026
Last Modified
August 21, 2026
First Seen
August 20, 2026

Related Vulnerabilities