n8n Sandbox Escape: A Workflow-Level Breach

In early 2026, a critical vulnerability in n8n exposed a flaw in a design assumption many DevOps and platform teams still rely on: that sandboxed workflow code is inherently safe.

Tracked as CVE-2025-68668, the issue allows an authenticated user to escape the Python execution sandbox and run arbitrary operating-system commands on the host running n8n. With a CVSS score of 9.9, this is not a marginal bug or edge case—it is a full trust boundary collapse between workflow logic and underlying infrastructure.

What makes this vulnerability especially dangerous is not clever exploitation or obscure primitives. It is dangerous because it is simple, reliable, and aligned with normal product usage.

From Workflow Logic to Host Execution

n8n is frequently deployed as a central automation hub. It orchestrates CI/CD pipelines, cloud operations, data flows, credential handling, and integrations across SaaS platforms and internal systems. In many environments, it runs continuously, with persistent network access and highly sensitive secrets loaded into memory.

That context matters.

CVE-2025-68668 effectively transforms any user who can modify workflows into a potential host-level attacker. This is not “workflow abuse.” It is an infrastructure compromise via a trusted automation layer.

What Actually Went Wrong

The vulnerable component is the Python Code Node, which relies on Pyodide—a WebAssembly-based Python runtime intended to execute Python safely in constrained environments.

In theory, Pyodide enforces isolation by limiting access to:

the filesystem
system processes
host runtime interfaces

However, in n8n’s implementation, Python execution did not exist in isolation. The Pyodide runtime was embedded inside a broader Node.js execution context, and the boundary between “sandboxed Python” and “host-capable JavaScript” was not airtight.

Under specific conditions, user-controlled Python objects could interact with internal execution paths exposed by the Node.js environment. Once that boundary was crossed, Python code was no longer constrained by WebAssembly rules—it could reach interfaces capable of spawning commands on the host.

At that point, execution occurred with the same privileges as the n8n process itself. This is why the issue is classified as CWE-693: Protection Mechanism Failure. The sandbox existed, but it failed under attacker-controlled input.

Why Exploitation Is So Dangerous

This vulnerability does not require:

administrative privileges
user interaction
social engineering
chained vulnerabilities

The only prerequisite is permission to create or modify workflows.

That permission is often intentionally broad. Automation platforms are designed to empower engineers, analysts, and operators. In n8n’s case, that trust became the attack surface.

Once the sandbox is bypassed, an attacker can:

read environment variables and secrets
execute arbitrary system commands
pivot into connected cloud services
establish persistence on the host
use n8n as a trusted execution proxy inside the network

In shared DevOps platforms or multi-tenant deployments, this becomes especially severe.

Illustrative Example: Where the Boundary Failed

Below is a conceptual illustration (not an exploit) showing how the failure class emerges when sandboxed execution and host execution share context.

# User-supplied Python logic inside a Code Node

data = {"lc": "unexpected_internal_object"}

# Serialized and passed through internal execution paths

process(data)

In isolation, this should remain inert. But during serialization and deserialization across Python and Node.js boundaries, internal object handling logic could misinterpret user-controlled structures as trusted runtime objects.

Once that trust is misplaced, execution flows into host-capable code paths.

This is not about “malicious Python.”It is about confused trust across execution layers.

Why the CVSS Score Is So High

Both the CNA and NVD scored this vulnerability at 9.9 (Critical) for good reason. The decisive factor is scope change. A low-privileged workflow permission escalates into full host compromise. Confidentiality and integrity impact are total, and availability impact depends only on attacker intent.

In practical terms:workflow access → system access

That is the worst possible escalation path in an automation platform.

The Fix Was Architectural, Not Cosmetic

n8n addressed the issue in version 2.0.0, and the nature of the fix is telling.

Instead of attempting to further harden Pyodide, n8n moved Python execution into task runner–based native isolation. Python now runs in separate execution contexts designed to reduce shared state and prevent cross-language trust confusion. This was not a patch. It was an acknowledgment that sandboxing dynamic languages inside workflow engines is fundamentally risky. Earlier versions had introduced this model as optional. With 2.0.0, it became the default.

Temporary Mitigations Are Not Enough

For teams unable to upgrade immediately, n8n recommended disabling Python execution, removing Code Nodes, or restricting workflow permissions. These steps reduce exposure—but they do not remove the flawed execution path.

As long as the old sandbox model exists, the boundary remains brittle.

Why This Matters Beyond n8n

This vulnerability is not an outlier. It reflects a broader industry problem.

Automation platforms are rapidly becoming control planes for infrastructure, but they are often secured like internal tools rather than Tier-0 systems. When a platform can execute code, handle secrets, and orchestrate infrastructure, it must be threat-modeled like CI/CD, IAM, or cloud control planes.

In that context, sandbox failures are equivalent to:

CI pipeline compromise
cloud role escalation
identity provider bypass

Final Takeaway

CVE-2025-68668 is a reminder that trust boundaries matter more than features. “Sandboxed” does not mean safe by default. Workflow permissions are security permissions. Automation engines are attack surfaces, not helpers.

As organizations automate more of their infrastructure, security failures will increasingly occur inside trusted systems—quietly, legitimately, and at scale. The real lesson from this incident is not about Python or Pyodide. It is about designing systems that assume every execution boundary will eventually be tested—and making sure it holds when it is.