Impact
A vulnerability in the Python Code node allows authenticated users to break out of the Python sandbox environment and execute code outside the intended security boundary.
Only authenticated users are able to execute code through Task Runners.
This issue affected any deployment in which the following conditions were met:
- Task Runners were enabled using N8NRUNNERSENABLED=true (default: false) - Python was enabled N8NPYTHONENABLED=true - Code Node was enabled (default: true)
In case the N8NRUNNERSMODE is set to external (default: internal) the sandbox escape is limited to the sidecar container with lower risk for lateral movement. In that case a lower high severity is more appropriate.
Patches
This vulnerability is fixed in version 2.4.8 and later.
Workarounds
If an immediate upgrade cannot be applied, the following hardening steps are recommended:
- Disable the Code Node by adding n8n-nodes-base.code to the NODESEXCLUDE environment variable - Prefer external mode for isolation: run Task Runners in external mode so that untrusted task code executes in a separate sidecar container rather than within the main n8n process. This configuration significantly reduces the risk of in-process memory disclosure caused by unsafe buffer allocations.In external mode, a launcher manages Task Runner processes in a dedicated sidecar environment, separate from the primary n8n instance. See the [n8n documentation](https://docs.n8n.io/hosting/configuration/task-runners/) for configuration details and required environment variables.
Resources
- n8n Documentation — Task Runners — external mode, setup guide, and environment configuration details - n8n Documentation — Blocking nodes — how to globally disable specific nodes
--- n8n has adopted CVSS 4.0 as primary score for all security advisories. CVSS 3.1 vector strings are provided for backward compatibility.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Impact
Additional exploits in the expression evaluation of n8n have been identified and patched following CVE-2025-68613.
An authenticated user with permission to create or modify workflows could abuse crafted expressions in workflow parameters to trigger unintended system command execution on the host running n8n.
Patches
The issue has been fixed in n8n versions 1.123.17 and 2.5.2. Users should upgrade to these versions or later to remediate the vulnerability.
Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only. - Deploy n8n in a hardened environment with restricted operating system privileges and network access to reduce the impact of potential exploitation.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Resources
- Best practices for securing n8n - Initial vulnerability advisory: CVE-2025-68613
---
n8n has adopted CVSS 4.0 as primary score for all security advisories. CVSS 3.1 vector strings are provided for backward compatibility.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
n8n contains a critical Remote Code Execution (RCE) vulnerability in its workflow Expression evaluation system. Expressions supplied by authenticated users during workflow configuration may be evaluated in an execution context that is not sufficiently isolated from the underlying runtime.
An authenticated attacker could abuse this behavior to execute arbitrary code with the privileges of the n8n process. Successful exploitation may lead to full compromise of the affected instance, including unauthorized access to sensitive data, modification of workflows, and execution of system-level operations.
Using string formatting and exception handling, an attacker may bypass n8n's python-task-executor sandbox restrictions and run arbitrary unrestricted Python code in the underlying operating system.
The vulnerability can be exploited via the Code block by an authenticated user with basic permissions and can lead to a full n8n instance takeover on instances operating under "Internal" execution mode.
If the instance is operating under the "External" execution mode (ex. n8n's official Docker image) - arbitrary code execution occurs inside a Sidecar container and not the main node, which significantly reduces the vulnerability impact.