A critical security vulnerability, designated CVE-2025-68668, has been identified in the popular open-source workflow automation platform, n8n. This flaw could allow an authenticated attacker to execute arbitrary system commands on the host machine running n8n, posing a significant risk to users of the platform. The vulnerability has been rated 9.9 on the Common Vulnerability Scoring System (CVSS), indicating its severe impact.
The issue specifically affects n8n versions ranging from 1.0.0 up to, but not including, 2.0.0. According to advisories, the vulnerability stems from a failure in a protection mechanism within the Python Code Node that utilizes Pyodide. This allows an authenticated user who has permissions to create or modify workflows to potentially compromise the underlying system by executing unauthorized operating system commands with the same privileges as the n8n process itself. The vulnerability has been fully addressed in n8n version 2.0.0.
n8n Security Vulnerability and Mitigation
The newly disclosed security flaw highlights a concerning protection mechanism failure within n8n’s Python Code Node. This vulnerability, CVE-2025-68668, enables authenticated attackers to achieve arbitrary code execution on the server hosting the n8n instance. The severity of the flaw is underscored by its CVSS score of 9.9, placing it in the critical category.
N8n’s development team has indicated that the Python Code Node’s reliance on Pyodide was the root cause of the vulnerability. This means that any authenticated user with the ability to manipulate workflows could potentially exploit this gap to run malicious commands, thereby gaining control over the n8n server environment. The security team has prioritized addressing this issue, integrating a fix in the latest release.
Understanding the Technical Aspects of the Flaw
The advisory explicitly mentions that the sandbox bypass vulnerability is present in the Python Code Node that employs Pyodide. This interaction between the node and the sandboxing technology was susceptible to exploitation. Consequently, an authenticated user with the necessary workflow permissions could leverage this weakness to execute arbitrary operating system commands on the host system. Importantly, these commands would run with the same privileges as the n8n process, increasing the potential damage.
N8n has been proactive in enhancing its security posture. In version 1.111.0, the platform introduced an optional, task runner-based native Python implementation designed for improved security isolation. This feature could be enabled via specific environment variables (N8N_RUNNERS_ENABLED and N8N_NATIVE_PYTHON_RUNNER). With the release of version 2.0.0, this more secure implementation has now been made the default, effectively mitigating the CVE-2025-68668 vulnerability for all users updating to the latest version.
Workarounds and Patching Recommendations for n8n Users
Until users can upgrade to n8n version 2.0.0, the platform has recommended several workarounds to mitigate the risks associated with CVE-2025-68668. These steps are crucial for maintaining the security of n8n deployments experiencing this vulnerability.
One immediate measure is to disable the Code Node entirely by setting the environment variable NODES_EXCLUDE to `[“n8n-nodes-base.code”]`. Alternatively, Python support within the Code Node can be disabled by setting the environment variable N8N_PYTHON_ENABLED to `false`. For those who require Python functionality but want to enhance security, configuring n8n to utilize the task runner-based Python sandbox is also recommended, by setting the N8N_RUNNERS_ENABLED and N8N_NATIVE_PYTHON_RUNNER environment variables.
This disclosure follows closely on the heels of n8n addressing another critical vulnerability, CVE-2025-68613, which also carried a CVSS score of 9.9 and had the potential for arbitrary code execution under specific conditions. The continuous identification and patching of such vulnerabilities are vital for maintaining the trust and security of DevOps environments that rely on workflow automation tools like n8n.
The expectation is that users will migrate to n8n version 2.0.0 as soon as possible to fully address both recently disclosed critical vulnerabilities. Continuous monitoring of n8n’s security advisories for any further updates or identified issues will be essential for ongoing protection.