n8n Sandbox Escape Lets Users Run System Commands

Cyera Research Labs disclosed a second critical vulnerability in n8n this month—a sandbox bypass in the Python Code Node that allows authenticated users to execute arbitrary operating system commands. CVE-2025-68668 carries a CVSS score of 9.9, just below maximum severity.

This disclosure follows CVE-2026-21858, the "Ni8mare" flaw we covered last week that enabled unauthenticated takeover. While that vulnerability has been patched, CVE-2025-68668 affects a different component and a different version range.

The Vulnerability

n8n's Python Code Node uses Pyodide, a WebAssembly-based Python runtime, to execute user-supplied scripts in workflows. The implementation includes a blocklist that restricts access to dangerous Python functions—the intent being that users can write automation logic without gaining shell access to the underlying server.

CVE-2025-68668 defeats this protection entirely.

Researchers discovered that _pyodide._base.eval_code() isn't blocked. By calling this internal function, attackers can execute arbitrary Python code outside the sandbox's restrictions. From there, they can interact with the host operating system.

The researchers codenamed the vulnerability "N8scape" because it escapes the sandbox that's supposed to contain Python execution.

Why Blocklists Fail

The flaw exposes a fundamental problem with blocklist-based sandboxing. The n8n developers identified dangerous functions and blocked them. But Python's internals provide multiple paths to the same capabilities, and the blocklist only covers the obvious routes.

From the researchers' analysis: "CVE-2025-68668 is a weakness in the security model of n8n's Pyodide-backed Python execution: n8n blocks a small set of risky functions, but it does not remove the underlying capabilities."

This pattern repeats across security products. Blocklists require defenders to enumerate every dangerous capability and every path to reach it. Miss one, and the entire protection collapses. The alternative—allowlists that explicitly permit only safe operations—tends to be more restrictive but more robust.

Affected Versions

CVE-2025-68668 affects n8n versions from 1.0.0 up to, but not including, 2.0.0. The vulnerability was addressed in the 2.0.0 release.

Organizations running any 1.x version with Python Code Node enabled should assume they're vulnerable.

Exploitation Requirements

Unlike the Ni8mare flaw, CVE-2025-68668 requires authentication. An attacker needs valid credentials and permission to create or modify workflows. But that bar isn't as high as it sounds.

n8n workflows often involve multiple team members with varying access levels. Anyone who can edit workflows—including junior engineers, contractors, or service accounts with overly broad permissions—can exploit the vulnerability. In shared hosting environments or managed service deployments, the blast radius extends to all workflows on the affected instance.

The attack requires no user interaction beyond normal workflow execution. An attacker creates a malicious workflow, triggers it, and gains command execution with n8n process privileges.

Mitigation Options

Upgrade to n8n 2.0.0 or later: This is the recommended fix. The 2.0.0 release addresses the sandbox escape.

Disable Python in Code Node: For organizations that can't immediately upgrade, setting N8N_PYTHON_ENABLED=false removes the attack vector. This environment variable was added in n8n 1.104.0.

Disable Code Node entirely: If Python automation isn't business-critical, NODES_EXCLUDE: ["n8n-nodes-base.code"] removes the vulnerable component from the platform.

Use task runner-based sandbox: n8n offers an alternative execution model via N8N_RUNNERS_ENABLED and N8N_NATIVE_PYTHON_RUNNER environment variables. This approach isolates Python execution more effectively than the Pyodide sandbox.

Broader Context

n8n has faced two critical vulnerabilities in two weeks. The pattern suggests that workflow automation platforms—which by design execute user-supplied code—present inherent security challenges that require careful architectural decisions.

Organizations using n8n should audit who has workflow editing permissions and whether that access is necessary. The principle of least privilege applies: if someone doesn't need to write Python code in workflows, they shouldn't have access to do so.

For security teams evaluating automation platforms, these disclosures highlight the importance of understanding execution models. How does the platform isolate user code? What happens if that isolation fails? The answers determine whether a workflow automation tool is an asset or a liability.