Two New n8n Sandbox Escapes: Can Workflow Editors Run Code on Your Server?

September 13, 2026

Two n8n expression-sandbox flaws could let workflow editors run server code, and one could reach a reviewer browser. See affected versions and fixes.

Yes. Two newly reviewed n8n vulnerabilities could let an authenticated workflow author escape the expression sandbox and execute code in the n8n server process. One path could also run JavaScript in an editor's browser during workflow preview. Both flaws are fixed in n8n 1.123.76, 2.37.7, and 2.38.2. They are serious, but neither advisory describes an unauthenticated internet attacker or confirmed exploitation in the wild.

The practical question is not whether every n8n user has been hacked. It is whether someone who can create or edit workflows should also be trusted with the server, its environment, its credentials, and the browser session of a person reviewing that workflow.

The answer changed for affected versions: the expression sandbox did not reliably enforce that separation.

This article explains CVE-2026-86076 and CVE-2026-86083 using n8n's coordinated GitHub advisories available on September 13, 2026. It separates the two technical paths, identifies who is actually exposed, and gives operators a concrete response plan.

What Is Confirmed

CVE-2026-86076 could turn workflow expressions into backend code execution

The reviewed CVE-2026-86076 advisory describes a flaw in n8n's expression compiler. The compiler used a dynamically scoped sanitizer. A class field named __sanitize could rebind that sanitizer and reach JavaScript's Function constructor.

That sounds abstract, but the security consequence is direct: an authenticated person allowed to author an expression could execute code inside the n8n process when the workflow ran.

Code running as the n8n process may be able to reach whatever that process can reach. Depending on the deployment, that could include:

• environment variables and service credentials;
• workflow data and stored execution results;
• files mounted into the container or host process;
• internal services reachable from the n8n network;
• APIs authorized through the instance;
• the ability to alter workflows or disrupt the service.

The advisory rates the flaw High at 8.7 under CVSS 4.0. It identifies affected versions below 1.123.76, the 2.0.0 through 2.37.6 line, and 2.38.0 through 2.38.1.

The same flaw could reach an editor's browser during preview

CVE-2026-86076 is not limited to backend execution. The advisory says a member's expression could run as JavaScript in the session of whoever opened the workflow in editor preview.

That creates a second trust boundary. A reviewer may believe they are inspecting an automation before approving it. If preview evaluates attacker-controlled expression code in the reviewer's browser session, opening the workflow can itself become the dangerous action.

The exact consequences depend on what the browser session exposes and which requests the user is authorized to make. The advisory does not claim universal account takeover. It does establish that the sandbox failure could cross from workflow content into another user's authenticated browser context.

This is why “only editors can exploit it” is not the same as “low risk.” Workflow editors often have legitimate access to build automations without being intended server administrators or trusted code deployers.

CVE-2026-86083 used shared global state to change generated code

The second reviewed advisory, CVE-2026-86083, describes a different escape in n8n's legacy expression engine.

Two code-generation stages called the global JSON.stringify function while building source text. An expression could replace that shared global. Later code generation would then use the attacker-controlled function, allowing data that should have remained a literal to become executable source.

In plain language, the sandbox trusted a shared tool while writing the code it planned to run. A workflow expression could tamper with that tool first and influence the next piece of generated code.

The issue was fixed by capturing a trusted reference at module load so later changes to global state could not change how source was generated.

GitHub rates CVE-2026-86083 High at 7.7 under CVSS 4.0. Like the first flaw, it could affect confidentiality, integrity, and availability of the n8n process.

The two vulnerabilities do not have identical exposure

The advisories share a patch set, but operators should not collapse them into one vague “n8n RCE.”

This distinction matters during triage. Switching to the vm expression engine specifically removes the CVE-2026-86083 path and is recommended as temporary mitigation for CVE-2026-86076, but the advisories still say workarounds do not fully remediate the risk. Upgrading is the fix.

The fixed versions are explicit

Both advisories identify the same fixed releases:

• n8n 1.123.76;
• n8n 2.37.7;
• n8n 2.38.2;
• or a later release on a supported line.

The 1.123.76 release, 2.37.7 release, and 2.38.2 release give operators concrete upgrade targets.

Do not assume that “2.x” means patched. Versions 2.38.0 and 2.38.1 are among those explicitly listed as affected by CVE-2026-86076.

What Is Still Unclear

The public advisories do not establish exploitation in the wild

Neither reviewed advisory says attackers exploited these flaws against production instances before the fixes were released. No public victim count, exposed-instance count, forensic indicator list, or incident timeline appears in the records reviewed for this article.

That is not proof that exploitation did not happen. It means operators should avoid both extremes:

• do not claim a mass breach without evidence;
• do not treat the absence of a public incident report as proof that an affected instance is clean.

The right response is version verification, access review, workflow inspection, and log analysis proportional to the sensitivity of the instance.

An n8n login alone was not enough

The advisories describe attackers who could create or modify workflows and author expressions. They do not say that any anonymous visitor could send one request to a default internet-facing n8n instance and immediately execute code.

Real exposure therefore depends on role design and deployment details:

• Who could create, import, share, or edit workflows?
• Could contractors, customers, trial users, or compromised accounts obtain that role?
• Did a more privileged person preview workflows created by someone else?
• Was the affected expression engine enabled?
• What files, secrets, networks, and APIs could the n8n process access?

Authentication narrows the path. It does not eliminate the impact when workflow-authoring access was meant to be less powerful than server administration.

The advisories do not prove which secrets were reachable in any one deployment

“Code execution in the n8n process” describes capability, not a universal data inventory. A hardened container with a restricted service account, narrow mounts, isolated credentials, and limited network egress presents a smaller blast radius than a privileged host process with broad cloud credentials.

Do not turn a platform-level vulnerability into unsupported claims about a specific organization's data. Confirm the process identity, environment, mounts, network routes, credential stores, and integrations for the actual deployment.

Why These n8n Sandbox Escapes Matter

A workflow permission became a code-deployment permission

Low-code tools deliberately let more people create useful automation. Their permission models often separate workflow authors from infrastructure administrators.

A sandbox escape collapses that separation:

edit a workflow → author an expression → escape evaluation limits → run as the automation server

That chain is dangerous because an automation server is rarely empty. Its purpose is to connect systems. It may hold credentials for email, databases, cloud storage, CRMs, ticketing systems, and AI providers. The value of the server is also the value of its attack surface.

Preview is part of the security boundary

Review is normally a safety control. A second person opens a workflow, inspects its nodes, and decides whether it should run.

CVE-2026-86076 shows why preview must be treated as execution, not passive reading. If preview evaluates expressions, the reviewer needs the same caution they would apply to opening an untrusted document with active content.

For shared automation environments, distinguish at least three permissions:

1. Who can submit or import workflow content?
2. Who can preview or evaluate that content?
3. Who can publish or execute it against real credentials?

Combining all three in one broad “editor” role increases the damage a compromised account or malicious collaborator can cause.

A sandbox needs isolation from both capabilities and mutable internals

The two flaws illustrate different failure classes.

CVE-2026-86076 exposed a powerful capability through a sanitizer lookup. CVE-2026-86083 let untrusted code modify a shared built-in that the compiler later trusted.

That gives defenders a useful review question: does untrusted code merely lack obvious dangerous names, or is it actually isolated from dangerous capabilities, shared mutable state, and code-generation machinery?

A denylist can miss an unexpected route. A frozen or separately instantiated environment can still have design flaws, but it reduces the number of shared objects an attacker can repurpose.

This broader containment lesson also appears in the DeepSeek Harness sandbox escape, where a local agent could reach the control plane that changed its own permissions, and in the OpenAI-Hugging Face incident, where surrounding infrastructure defeated the intended evaluation boundary.

The mechanisms differ. The durable principle is the same: a sandbox is only as strong as every privileged path reachable from inside it.

What n8n Operators Should Do Now

1. Verify the running version, not only the deployment manifest

Confirm the version reported by the active n8n process. A container tag, lockfile, or infrastructure template may not match the process serving traffic after a failed rollout or stale restart.

Upgrade to 1.123.76, 2.37.7, 2.38.2, or a later supported release. If multiple workers, task runners, preview services, or environments exist, verify each one.

2. Treat engine switching as temporary risk reduction

Both advisories recommend setting N8N_EXPRESSION_ENGINE=vm when immediate upgrading is not possible. CVE-2026-86083 explicitly does not affect the newer vm engine.

The advisories also warn that workarounds do not fully remediate the risk. Use the setting to reduce exposure while completing the upgrade, not as a reason to leave an affected version running indefinitely.

3. Restrict workflow-authoring access

Review every account and group allowed to create, import, share, or edit workflows. Remove stale users, temporary collaborators, unnecessary service accounts, and broad default roles.

Require stronger authentication for authors and administrators. If the instance supports external identity controls, verify that group membership and offboarding still work as intended.

4. Audit workflows and recent access

The CVE-2026-86076 advisory specifically recommends checking for unexpected or unfamiliar expressions in node parameters.

Prioritize:

• workflows created or edited by unusual accounts;
• expressions containing unfamiliar class syntax or sanitizer-related names;
• unexpected modifications around preview or production runs;
• new credentials, webhooks, nodes, or outbound destinations;
• server process activity inconsistent with ordinary n8n execution;
• suspicious access following a workflow preview.

Do not rely only on a string search for one public technique. The advisories describe vulnerability mechanisms, not a complete catalog of every payload an attacker could construct.

5. Reduce the n8n process blast radius

Run n8n as a dedicated low-privilege operating-system user, as the CVE-2026-86083 advisory recommends. Then review:

• filesystem mounts and writable paths;
• environment variables and injected secrets;
• database privileges;
• cloud instance roles;
• container privileges and host sockets;
• internal network reachability;
• outbound internet access;
• credentials available to individual workflows.

Rotate a credential because evidence shows it may have been accessed, because the affected process could read it and you cannot establish integrity, or because your incident-response policy requires rotation—not merely because the credential exists somewhere in the organization.

6. Separate authoring, review, and production

Use a test instance with synthetic data and test credentials for workflows from less-trusted authors. Promote reviewed workflows into production through a controlled process rather than letting every creator work directly beside live secrets.

That architecture will not erase application vulnerabilities. It can keep one workflow mistake or compromised editor from immediately inheriting the organization's largest possible blast radius.

Where OpenVeil Fits—and Where It Does Not

These advisories are about a workflow automation platform executing expressions. OpenVeil is a different kind of product: a privacy-focused hosted AI workspace for adults who want conversational AI without storing normal chat history as a server-side account record.

OpenVeil can be a simpler choice when the task is to ask a question, draft text, analyze a file, or search without giving an autonomous workflow engine ongoing access to business systems. Normal OpenVeil chat history stays in the user's browser, and OpenVeil does not use prompts, uploaded material, selected local history, or generated output to train foundation models.

The boundary matters. OpenVeil is not an n8n patch, expression sandbox, workflow scanner, credential vault, endpoint-security product, firewall, or incident-response service. It does not protect an n8n server after arbitrary code runs. Active OpenVeil requests are still processed by OpenVeil and necessary AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers.

If you do not need workflow execution, connected-service authority, or background automation for a particular task, reducing that authority is itself a privacy and security choice. You can try OpenVeil's one-time preview without a card.

For a broader comparison, see local AI versus hosted AI privacy tradeoffs.

Frequently Asked Questions

Can an anonymous attacker exploit CVE-2026-86076 or CVE-2026-86083?

The reviewed advisories describe low-privilege authenticated access with the ability to author or edit workflow expressions. They do not establish a default unauthenticated remote path. A separate authentication flaw, exposed account, malicious collaborator, or unsafe role assignment could change a real deployment's risk.

Which n8n versions fix the two expression sandbox escapes?

Both advisories list n8n 1.123.76, 2.37.7, and 2.38.2 as fixed. Later supported releases should include the fixes. Verify the version of every running component after upgrading.

Is the n8n vm expression engine affected?

CVE-2026-86083 affects only the legacy expression engine; its advisory says the vm engine is not affected. The CVE-2026-86076 advisory also recommends switching to vm as a temporary mitigation. Neither advisory treats that workaround as a substitute for upgrading.

Did these n8n flaws expose stored credentials?

The advisories establish code execution in the n8n process, which could create access to credentials reachable by that process. They do not identify a universal set of exposed credentials or confirm a public breach. Operators must determine what their particular process could access and whether logs or integrity evidence justify rotation.

Could opening a workflow be dangerous?

For CVE-2026-86076, yes under the affected conditions. The advisory says an expression could execute JavaScript in the browser session of a person who opened the workflow in editor preview. Patched versions reject the reserved class-member names used by that path.

Does OpenVeil fix or monitor n8n?

No. OpenVeil is a hosted conversational AI workspace, not an automation-platform security control. It can reduce unnecessary agent or workflow authority when a user only needs a private AI conversation, but n8n operators must patch and secure n8n directly.

The Bottom Line

CVE-2026-86076 and CVE-2026-86083 show two ways an expression sandbox can fail: one exposed a powerful constructor through sanitizer rebinding, while the other let an expression tamper with a shared built-in used to generate later code.

Both could turn workflow-authoring access into code execution as the n8n process. One could also cross into an editor's browser during preview. The fixes are available and explicit: upgrade to n8n 1.123.76, 2.37.7, 2.38.2, or later; restrict workflow authors; audit unexpected expressions and access; and keep the automation process on the smallest possible set of credentials, files, and networks.

What is not confirmed is equally important: the public records do not establish mass exploitation, a victim count, or a universal data breach. Patch the known vulnerability, investigate the environment you actually run, and describe any incident only as far as the evidence supports.

Sources

• GitHub Advisory: CVE-2026-86076 / GHSA-hw8v-xxg5-vvvx
• GitHub Advisory: CVE-2026-86083 / GHSA-6xcw-7xm6-48c6
• n8n release 1.123.76
• n8n release 2.37.7
• n8n release 2.38.2