Critical n8n Vulnerability (CVSS 9.9) Lets Authenticated Users Execute System Commands — What You Need to Know

A newly disclosed critical security vulnerability in the popular open-source n8n workflow automation platform has sent shockwaves through the DevOps and automation community. Tracked as CVE-2025-68668 and assigned a near-maximum CVSS score of 9.9, this flaw could allow an authenticated user to execute arbitrary system commands on the host server running n8n — effectively leading to a full compromise of the affected system.

In this in-depth article, we unpack how this vulnerability works, which versions are affected, what the real-world risks are, how you can mitigate exposure, and the broader implications for organizations relying on workflow automation platforms.

What Is n8n and Why It Matters

n8n (short for “node-eight-node”) is an open-source workflow automation platform that enables developers and IT teams to build automated integrations and workflows between applications, APIs, databases, and services. It’s often self-hosted and widely used in enterprises and DevOps environments to orchestrate business logic, connect SaaS tools, and automate repetitive tasks.

Because n8n instances often have access to internal systems, credentials, APIs, and production data, any security issue in the platform — especially one that allows code execution at the server level — poses serious operational and security risks.

The Vulnerability: CVE-2025-68668 Explained

The newly disclosed vulnerability, CVE-2025-68668, has been identified as a protection mechanism failure that impacts the way n8n handles workflow logic — specifically the Python Code Node feature.

Here’s how it works:

• n8n includes a feature that allows workflow designers to embed Python code inside automation workflows.
• This Python code is executed within a sandbox environment using Pyodide, a WebAssembly-based runtime meant to isolate user code from the underlying system.
• Due to improper sandboxing and insufficient isolation of the execution context, authenticated users with workflow creation or modification permissions can escape the sandbox and run *arbitrary system commands on the host machine with the privileges of the n8n process.

Because this flaw allows system-level command execution, attackers can perform actions far beyond what typical workflow modifications would permit. They can manipulate system configuration, access sensitive data, install backdoors, or pivot to other parts of a network.

Severity: Why a 9.9 CVSS Matters

A CVSS score of 9.9 out of 10 places this vulnerability in the Critical category. CVSS, the Common Vulnerability Scoring System, evaluates the technical severity of software weaknesses based on factors such as:

• Complexity of exploitation
• Authentication required
• Privilege level needed
• Potential impact on confidentiality, integrity, and availability
• Whether user interaction is required

CVE-2025-68668 is rated 9.9 because:

• It can be exploited over the network, usually via the web interface or API.
• It requires only authenticated access (which many instances expose to internal user pools).
• It enables arbitrary command execution at the operating system level.
• The underlying n8n process often runs with access to sensitive workflows, tokens, and credentials.

In practical terms, this means that once a valid user account is compromised — or if a low-trust user is allowed to design workflows — the vulnerability could be abused for full server takeover.

Versions Affected

The flaw impacts a wide range of n8n releases from the beginning of the 1.x release series until just before 2.0.0.

Specifically:

• Affects n8n versions from 1.0.0 up to, but not including, 2.0.0.
• Users running any version in that range should consider themselves at risk unless patches or mitigations are applied.

Notably, the vulnerability has been addressed in version 2.0.0, where the Python sandbox implementation has been revised and made more secure by default.

Technical Root Cause: Sandbox Escape in Python Code Node

At the heart of the flaw is a sandbox bypass in the Python Code Node component.

Here’s the deeper explanation from security analysis:

• The Python Code Node uses Pyodide, a WebAssembly-based Python runtime, to execute user-supplied code within workflows.
• Pyodide was intended to isolate the code from the host environment.
• However, due to architectural shortcomings, it failed to prevent user Python from accessing Node.js objects and the underlying host environment.
• This meant that with crafted input, attackers could reach higher privileges than intended, including native modules like the Node.js child_process module, and from there execute system commands.

This is not just a coding error: it’s a fundamental failure of the sandboxing model that lets user-controlled components interact with the core execution environment.

What Attackers Could Do With This

An attacker who successfully exploits CVE-2025-68668 could potentially:

• Run arbitrary commands on the n8n server, including downloading and executing malware.
• Access all stored credentials, API tokens, and secrets that workflows interact with.
• Modify, delete, or create new workflows to enable further malicious automation.
• Harvest sensitive data or configuration files stored on the host.
• Use the compromised server as a pivot point to attack internal networks.
• Install persistent backdoors or command-and-control infrastructure.

Because n8n often resides in internal or semi-internal networks — bridging different SaaS applications and internal services — this flaw magnifies the potential blast radius of an initial breach.

Proof-of-Concept and Public Details

Security analysts have already described the mechanics of the flaw in detail, and proof-of-concept (PoC) details have been circulated within the security community. These disclosures demonstrate just how easy it might be for attackers — particularly those with internal access — to transform this vulnerability into a full server takeover.

While exploitation requires valid authentication, the combination of a critical flaw, PoC availability, and broad adoption of n8n emphasizes the urgent need for remediation.

How to Mitigate the Risk

Because the vulnerability can be used to run arbitrary system commands, even relatively restricted environments can be exposed if:

• A stolen credential is used
• A compromised internal account is abused
• A malicious insider has access
• A self-hosted instance is publicly exposed

Here’s what organizations should do:

1. Upgrade to n8n 2.0.0 or Later

The safest and most straightforward mitigation is to update all n8n installations to version 2.0.0 or newer where the issue has been fixed. This version includes an improved Python sandbox and other hardening measures that close the escape vector.

2. Restrict Workflow Creation Permissions

Limit who can create, modify, or execute workflows in n8n to only fully trusted administrators or power users. Restricting these privileges reduces the chance that an attacker with legitimate credentials will have the ability to exploit this type of vulnerability.

3. Disable the Affected Features Temporarily

For environments that cannot immediately upgrade, temporary workarounds include:

• Disabling the Code Node entirely (setting environment variables like NODES_EXCLUDE: ["n8n-nodes-base.code"]).
• Disabling Python execution in the Code node (N8N_PYTHON_ENABLED=false).
• Configuring n8n to use a more isolated task-runner-based Python sandbox using N8N_RUNNERS_ENABLED and N8N_NATIVE_PYTHON_RUNNER environment variables.

These mitigations reduce exposure until a full upgrade can be applied.

Who Should Prioritize This Patch?

Any organization or team using n8n should treat this vulnerability with high urgency:

• Enterprises automating critical business processes
• DevOps teams managing production workflows
• Teams storing credentials, tokens, or sensitive API connections in n8n
• Self-hosted n8n instances exposed to internal or external networks
• Managed n8n services where tenant isolation may not be strong

Because n8n is often deployed with internal connectivity and accesses multiple services, a compromise here could expose far more than just one platform.

Broader Context: Workflow Automation Risks

n8n is not the only workflow automation tool under scrutiny. Platforms that allow complex logic, code execution, and integrations with sensitive systems often represent attractive targets:

• They connect multiple systems together
• They often store long-lived credentials
• They may handle sensitive business processes
• They are frequently exposed to internal users with broad access

Finding a vulnerability in n8n’s sandbox implementation highlights a larger trend: when automation platforms merge code execution, third-party integrations, and internal connectivity without strict isolation, the attack surface expands dramatically.

Organizations must treat workflow automation tools not as peripheral utilities, but as integral parts of their attack surface that require security first design and maintenance.

Conclusion: Urgent Patch and Defense Required

The disclosure of CVE-2025-68668 — a *critical workflow automation vulnerability rated 9.9 on the CVSS scale — serves as a stark reminder that widely adopted tools can harbor deep architectural flaws with severe consequences. Authenticated users with workflow permissions can, under this vulnerability, execute system commands on the n8n host, posing risks ranging from data compromise to full server breach and lateral network attacks.

If your environment uses n8n:

1. Update to version 2.0.0 or later immediately.
2. Limit workflow editing and creation permissions to trusted users.
3. Apply temporary mitigations if immediate patching is not possible.
4. Monitor n8n logs and network traffic for unusual command execution patterns.

Staying current with security updates, applying the principle of least privilege, and regularly auditing workflow platforms are essential steps to protecting critical automation infrastructure.

Given the widespread use of n8n and its integration with internal workflows and credentials, addressing this vulnerability should be a top priority for DevOps, security teams, and IT leadership alike.