N8Scape (Pyodide sandbox escape): 9.9 Critical Post-Auth RCE in n8n (CVE-2025-68668)

TL;DR

Cyera Research Labs uncovered a critical vulnerability in n8n (CVE-2025-68668 CVSS 9.9) that enables attackers to compromise the n8n automation environment and abuse the trust it holds across connected systems. This finding follows our previous disclosure of Ni8mare, an unauthenticated remote code execution vulnerability in n8n (CVE-2026-21858, CVSS 10.0), highlighting a recurring pattern of high-impact security flaws in workflow automation platforms.

Motivation

What do attackers look for? One compromised server to rule them all.In the context of n8n (https://n8n.io/), a single successful exploit can quickly turn into an organization’s worst-case scenario.Modern AI workflow automation platforms are designed to orchestrate actions across a wide range of environments, often with near administrative privileges. As a result, they represent an enormous blast radius, including access to databases, SaaS applications, and cloud services, along with long-lived credentials such as API keys, OAuth tokens, and database passwords. Once exposed, these credentials can be reused to pivot deeper into an organization’s infrastructure.

Key Highlights

• n8n Is a Central Automation Control Plane, Not Just a Workflow Tool
  n8n typically sits at the center of business operations, orchestrating actions across SaaS platforms, databases, cloud APIs, identity systems, and internal services. A compromise of n8n is therefore a compromise of the organization’s automation control plane, not a single server or application.
• A Sandbox Escape Collapses Organizational Trust Boundaries
  Escaping the n8n Code node does not merely yield code execution - it collapses multiple trust boundaries at once: workflow logic, credential storage, and execution authority. From a single post-auth foothold, an attacker can read secrets, modify automations, and issue trusted actions across systems that normally never trust each other directly.
• Post-Auth RCE in n8n Enables Fast, Quiet, Organization-Wide Compromise
  Because n8n is designed to automate privileged actions using long-lived credentials, post-auth RCE immediately enables credential harvesting, lateral movement, persistence through workflows, and abuse of legitimate integrations. This makes compromise faster, stealthier, and broader than traditional application or server RCE.

Background: Automation Platforms and Agentic AI‍

^{Automation platforms are no longer just “workflow glue”. They’re increasingly execution engines with deep, trusted access to databases, cloud services, and internal systems, often operating with minimal human oversight. As organizations adopt agentic AI and workflow engines to orchestrate APIs and SaaS platforms, these systems concentrate credentials, trust, and execution power in a single place.}‍

^{Agentic AI frameworks amplify this trend: instead of a human clicking buttons, an agent can plan, take actions, and close operational loops. Workflow engines like n8n are frequently used as the execution layer for those actions, turning natural-language decisions into real infrastructure changes. That’s exactly why sandboxing mistakes in code-execution features become disproportionately high impact.}

Automation Swiss Army Knife: n8n Is Quietly Everywhere‍

^{n8n’s public workflow gallery contains 7,600+ published workflows, which is a useful proxy for how broadly teams use it across business and IT automation.}‍^‍

^{Here’s a representative “day-in-the-life” example of how n8n gets used in a normal organization: SalesOps receives a new inbound lead, a workflow pulls it from a form provider, enriches it, and writes it into Salesforce. A small Python Code node cleans the phone number format, dedupes by email, and tags the lead’s region so the right rep gets assigned. If enrichment fails, the workflow opens a Jira ticket and notifies the #revops Slack channel with enough context to triage quickly. Later, a scheduled job exports daily pipeline changes from Postgres into a finance report and emails it to stakeholders.}

^{This is normal usage, but notice what it implies: n8n sits in the middle of CRM access, database access, and internal communications, and it holds the tokens and passwords needed to automate all of it.}

The Code Node: Powerful by Design, Risky by Nature

^{The n8n Code node is the feature that turns n8n from a simple automation tool into a general-purpose execution engine. It allows users to run custom JavaScript or Python code directly inside a workflow, enabling logic that cannot be expressed with standard nodes alone. In practice, teams use the Code node for data transformation, conditional logic, enrichment, and handling edge cases across integrations.
When it comes to Python code execution, n8n historically used Pyodide (CPython compiled to WebAssembly, which is widely used in the browser and serverless ecosystems) with a small set of Python-level blocks intended to prevent dangerous operations.
The security issue: function-level blocking is not capability-level isolation. There are alternate paths to reach the same capability (OS command execution).}

The Mechanism Proof: What n8n Actually Blocks (Source Code)

^{The key point is what n8n blocks and more importantly what it doesn’t. In n8n source code, Pyodide is initialized and then n8n applies the following Python code (from `packages/nodes-base/nodes/Code/Pyodide.ts`):}

This is a blocklist. It blocks the usage of:

• os.system
• The JavaScript bridge (sys.modules['js'])
• A JavaScript Object.constructor.constructor path

But it does not block:

• ctypes (FFI to native functions)
• _pyodide._base.eval_code (an alternate execution path)

That gap is exactly what we exploited.

The Sandbox Architecture of n8n

^{This diagram is the mental model you should keep while reading the rest:}

Important boundary clarification

• We showed how you can escape the Pyodide “sandbox” (Python-level restrictions + WASM expectations).
• The resulting RCE runs with the n8n process privileges in the environment where n8n is running. If n8n runs in Docker/Kubernetes, that’s typically the container. If it runs directly on a VM/bare metal, it can be the host.

The Architectural Failure of Using Blocklist Trap

^{The vulnerability we found isn’t just “a missing patch”. It’s a structural problem which stems from a blocklist-based sandbox that implicitly assumes the defender can enumerate every dangerous capability and every path to reach it.} 

^{In practice, that means the platform owner (or every downstream user) must continuously audit a huge and evolving surface area of modules, builtins, and runtime features, and then decide which ones to remove or rewrite. That is a security model that degrades over time by default.}

^{The reality shows you may fail blocking obvious APIs like os.system. In addition you are actually playing a very dangerous adversarial game against creativity. An escape primitive can be trivial (a single overlooked module) or extremely non-obvious (for example, exploitation techniques like Sigreturn Oriented Programming, SROP, that build powerful behavior out of unexpected mechanisms) and defenders cannot reliably predict what the next bypass will look like.}

^{The only durable fix is to move from “deny a growing list of bad things” to capability-based isolation: run untrusted code in an environment that simply does not have the privileges to spawn processes, reach sensitive files, or access secrets, even if a clever path exists inside the language runtime. That is why process isolation, runners, and OS-level sandboxing are the long-term direction for safely supporting code execution features.}

Explaining CVE-2025-68668

^{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.}

^{Two independent bypasses were confirmed:}

^{Bypass #1: ctypes to invoke libc.system() directly.}

^{Bypass #2: _pyodide._base.eval_code() to execute code in a context where n8n’s patches aren’t applied.}

^{For the official advisory details, see GHSA-62r4-hw23-cc8v.}

Exploit Path 1: Escaping the sandbox Restrictions via ctypes

Why it works

^{The component os.system is only a wrapper. n8n replaces the wrapper with a function that raises an exception, but the underlying capability (invoke `system()`) can still be reached via Python’s Foreign Function Interface.}

^{Proof of Concept: With as little as 2 lines of code, n8n escape can be executed.}

Runtime Mechanics of the Escape:

• ctypes is available, so untrusted code can load the process’ exported symbols (`CDLL(None)`).
• The call invokes system() without ever touching os.system.
• Result: OS command execution with the same privileges as the n8n process.

Exploit Path 2: Escaping the Sandbox via Code Eval

Why it works (concretely)

^{N8N enforces its security blocks by modifying Python's namespace in the main Pyodide runtime - replacing dangerous functions like os.system with stubs that raise "Blocked for security reasons" errors. These patches are applied at initialization time via pyodideInstance.runPythonAsync(), effectively poisoning the main module namespace.}

^{In practice, that means eval_code(...) can execute code in a context where the patched os.system reference is not the one being used, enabling command execution despite the patch.}

^{Proof of Concept: With as little as 2 lines of code, n8n escape can be executed.}

^{Result: the command runs successfully, returning a normal exit code (instead of raising “Blocked for security reasons”).}

From RCE to Platform-wide compromise

^{The discovery of CVE-2025-68668 is a critical event because it represents a total collapse of the trust boundaries within an organization's automation infrastructure. Imagine you are part of a large enterprise where, as part of your onboarding, you receive access to a centralized n8n instance. This platform serves as the organization's automation control plane, used by the SOC, DevOps, and even HR for sensitive workflows. Because n8n orchestrates these critical operations, it functions as an execution engine with deep, trusted access to your most sensitive environments.}

^{A compromise of this system means an attacker gains access to the "keys to the kingdom", including cloud infrastructure credentials, private user data, and long-lived API tokens for platforms like Salesforce, Zendesk, or internal databases. The vulnerability turns n8n into an attacker's dream, allowing them to transform a low-privilege account into a total control plane.}

From User to Admin: Collapsing the Trust Boundary 

^{The core of the danger lies in how this sandbox escape enables privilege escalation. In a standard deployment, n8n maintains strict segregation: a regular user can only see their own personal workflows and credentials, while an admin has a global view of every integration in the company.}

^{By exploiting this vulnerability, an attacker can escape the Python sandbox to gain Remote Code Execution (RCE) with the same privileges as the n8n process itself. Since the n8n database is mounted to the container, an attacker with RCE can modify the database directly while it is running. This allows them to manually change their own status from a "user" to an "admin or owner”, instantly gaining visibility into every secret and credential configured across the entire organization.}

‍

RCE and privilege escalation POC  

^{The following demonstration illustrates how a simple two-line Python script can bypass security restrictions to achieve full command execution on the host.}

Mitigation and Remediation

Immediate (if you cannot upgrade right now)

• Disable Python execution (if supported in your deployment):

• Alternatively, disable the Code node entirely:

For more information please refer to https://docs.n8n.io/hosting/configuration/environment-variables/nodes/#nodes-environment-variables.

Longer-term (recommended)

• Upgrade to the n8n architecture that provides proper process isolation for Python execution (runner-based model), per vendor guidance in the advisory.

Timeline and Disclosure

• 27 Oct 2025: Reported to n8n via GitHub Security.
• 27 Oct 2025: Acknowledged by maintainers.
• 24 Nov 2025: Advisory activity / mitigation guidance emphasized.
• 24 Dec 2025: Vulnerability patched; affected behavior limited to the legacy, deprecated Pyodide execution mode.

CVSS 9.9 - Plain-English Justification

The CVSS score was calculated according to industry standards with CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L. Read more GHSA-62r4-hw23-cc8v.

• AV:N: the attacker interacts over the network (web UI / API) to modify and execute workflows.
• AC:L: exploitation is trivial (few lines of Python, no race conditions, no special environment required beyond vulnerable configuration).
• PR:L: attacker needs a low-privilege account that can create/edit workflows (common in many deployments).
• UI:N: no victim click is required once the attacker has permissions.
• S:C: compromise crosses a trust boundary, from “workflow authoring” into “code execution that can impact other connected systems and data”.
• C:H / I:H: once RCE is achieved, confidentiality and integrity impact are high (access to secrets + ability to modify automation and data flows).
• A:L: availability impact is not necessarily maximal by default; many attacks focus on stealthy access and data theft, not service destruction.

Collaboration with N8N Security Team 

We thank the n8n security team for their prompt acknowledgment and responsive handling of this disclosure. Their commitment to addressing the issue and communicating a hardened runner-based architecture as the long-term fix demonstrates a mature approach to security.