See how n8n compares to other vendors in security performance
Impact n8n contains a critical Remote Code Execution (RCE) vulnerability in its workflow expression evaluation system. Under certain conditions, 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.
Patches This issue has been fixed in n8n v1.122.0.
Users are strongly advised to upgrade to version 1.122.0 or later, which introduces additional safeguards to restrict expression evaluation.
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 eliminate the risk and should only be used as short-term measures.
Impact n8n is affected by an authenticated Remote Code Execution (RCE) vulnerability.
Under certain conditions, an authenticated user may be able to cause untrusted code to be executed by the n8n service. This could result in full compromise of the affected instance.
Both self-hosted and n8n Cloud instances are impacted.
Patches The issue has been resolved in n8n version 1.121.3.
Users are advised to upgrade to this version or later to fully address the vulnerability.
Workarounds If upgrading is not immediately possible, administrators can reduce exposure by disabling the Git node and limiting access for untrusted users.
References - n8n documentation: Blocking access to nodes
Impact A vulnerability in n8n allows an attacker to access files on the underlying server through execution of certain form-based workflows. A vulnerable workflow could grant access to an unauthenticated remote attacker. This could result in exposure of sensitive information stored on the system and may enable further compromise depending on deployment configuration and workflow usage.
Patches The issue has been fixed in n8n version 1.121.0. Users should upgrade to this version or later to remediate the vulnerability.
Workarounds No official workarounds are available. As a temporary mitigation, users may restrict or disable publicly accessible webhook and form endpoints until upgrading.
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.
Impact An authenticated user with permission to create or modify workflows could use the Python Code node to escape the sandbox. The sandbox did not sufficiently restrict access to certain built-in Python objects, allowing an attacker to exfiltrate file contents or achieve RCE.
On instances using internal Task Runners (default runner mode), this could result in full compromise of the n8n host. On instances using external Task Runners, the attacker might gain access to or impact other task executed on the Task Runner.
- Task Runners must be enabled using N8NRUNNERSENABLED=true.
Patches The issue has been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to this version 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. - Disable the Code node by adding n8n-nodes-base.code to the NODESEXCLUDE environment variable.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact An authenticated user with permission to create or modify workflows could leverage the Merge node's SQL query mode to execute arbitrary code and write arbitrary files on the n8n server.
Patches The issues have been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of these versions or later to remediate all known vulnerabilities.
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. - Disable the Merge node by adding n8n-nodes-base.merge to the NODESEXCLUDE environment variable.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact A sandbox bypass vulnerability exists in the Python Code Node that uses Pyodide.
An authenticated user with permission to create or modify workflows can exploit this vulnerability to execute arbitrary commands on the host system running n8n, using the same privileges as the n8n process.
Patches In n8n version 1.111.0, a task-runner-based native Python implementation was introduced as an optional feature, providing a more secure isolation model.
To enable it, you need to configure the N8NRUNNERSENABLED and N8NNATIVEPYTHONRUNNER environment variables.
This implementation became the default starting with n8n version 2.0.0.
Workarounds - Disable the Code Node by setting the environment variable NODESEXCLUDE: "[\"n8n-nodes-base.code\"]" (Docs) - Disable Python support in the Code node by setting the environment variable N8NPYTHONENABLED=false, which was introduced in n8n version 1.104.0. - Configure n8n to use the task runner based Python sandbox via the N8NRUNNERSENABLED and N8NNATIVEPYTHONRUNNER environment variables. (Docs)
Resources - n8n documentation: Blocking access to nodes - n8n documentation: Code Node (Python) - n8n documentation: Task Runners
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.
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
Vulnerabilities in the Git node allowed authenticated users with permission to create or modify workflows to execute arbitrary system commands or read arbitrary files on the n8n host.
Patches
The issue has been fixed in n8n versions 2.5.0, and 1.123.10. Users should upgrade to this version 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. - Restrict or disable access to the Git node if not essential for operations. - 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
- 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
Impact
A vulnerability in the file access controls allows authenticated users with permission to create or modify workflows to read sensitive files from the n8n host system. This can be exploited to obtain critical configuration data and user credentials, leading to complete account takeover of any user on the instance.
Patches
The issue has been fixed in n8n version 1.123.18 and 2.5.0. Users should upgrade to this version 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. - Restrict access to nodes that interact with the file system, particularly the "Read/Write Files from Disk" and "Git" nodes.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Resources
- 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 An authenticated user with permission to create or modify workflows could exploit a vulnerability in the JavaScript Task Runner sandbox to execute arbitrary code outside the sandbox boundary.
On instances using internal Task Runners (default runner mode), this could result in full compromise of the n8n host. On instances using external Task Runners, the attacker might gain access to or impact other task executed on the Task Runner. - Task Runners must be enabled using N8NRUNNERSENABLED=true.
Patches The issue has been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of 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. - Use external runner mode (N8NRUNNERSMODE=external) to limit the blast radius.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Resources - n8n Documentation — Task Runners
Impact A second-order expression injection vulnerability existed in n8n's Form nodes that could allow an unauthenticated attacker to inject and evaluate arbitrary n8n expressions by submitting crafted form data. When chained with an expression sandbox escape, this could escalate to remote code execution on the n8n host.
The vulnerability requires a specific workflow configuration to be exploitable: 1. A form node with a field interpolating a value provided by an unauthenticated user, e.g. a form submitted value. 2. The field value must begin with an = character, which caused n8n to treat it as an expression and triggered a double-evaluation of the field content. For example, a workflow uses a multi-step Form where a downstream Form node renders user-provided input back in an HTML field and precedes it with an = sign: =<h2>Thank you, {{ $input.first().json[\"Name\"] }}!</h2>
There is no practical reason for a workflow designer to prefix a field with = intentionally — the character is not rendered in the output, so the result would not match the designer's expectations. If added accidentally, it would be noticeable and very unlikely to persist. An unauthenticated attacker would need to either know about this specific circumstance on a target instance or discover a matching form by chance.
Even when the preconditions are met, the expression injection alone is limited to data accessible within the n8n expression context. Escalation to remote code execution requires chaining with a separate sandbox escape vulnerability.
Due to these real-world constraints — the unlikely workflow configuration, the need for an additional sandbox escape, and the difficulty of discovery — we have assessed the severity as High rather than Critical, diverging from the base CVSS score to better reflect actual exploitability.
Patches The issue has been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of these versions or later to remediate the vulnerability.
Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Review usage of form nodes manually for above mentioned preconditions. - Disable the Form node by adding n8n-nodes-base.form to the NODESEXCLUDE environment variable. - Disable the Form Trigger node by adding n8n-nodes-base.formTrigger to the NODESEXCLUDE environment variable.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact
The n8n Git node allows workflows to set arbitrary Git configuration values through the Add Config operation. When an attacker-controlled workflow sets core.hooksPath to a directory within the cloned repository containing a Git hook such as pre-commit, Git executes that hook during subsequent Git operations. Because Git hooks run as local system commands, this behavior can lead to arbitrary command execution on the underlying n8n host.
Successful exploitation requires the ability to create or modify an n8n workflow that uses the Git node.
Affected versions: ≥ 0.123.1 and < 1.119.2
Patches
This issue has been patched in n8n version 1.119.2.
All users running affected versions should upgrade to 1.119.2 or later.
Workarounds
If upgrading is not immediately possible, the following mitigations can reduce exposure:
- Exclude the Git node (Docs). - Avoid cloning or interacting with untrusted repositories using the Git Node.
Impact
A vulnerability in the Merge node's SQL Query mode allowed authenticated users with permission to create or modify workflows to write arbitrary files to the n8n server's filesystem potentially leading to remote code execution.
Patches
The issue has been fixed in n8n version 2.4.0, 1.118.0. Users should upgrade to this version 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. - Disable or restrict use of the Merge node if not essential for operations. - Review workflows for suspicious use of the Merge node's SQL Query mode.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Resources
- 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 backwards compatibility.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Impact A Command Injection vulnerability was identified in n8n’s community package installation functionality. The issue allowed authenticated users with administrative permissions to execute arbitrary system commands on the n8n host under specific conditions.
Important context
- Exploitation requires administrative access to the n8n instance. - The affected functionality is restricted to trusted users who are already permitted to install third-party community packages. - No unauthenticated or low-privilege exploitation is possible. - There is no evidence of exploitation in the wild.
Because administrative users can already extend n8n with custom or community code, the vulnerability does not meaningfully expand the threat model beyond existing administrator capabilities. However, it represents a violation of secure coding practices and has therefore been addressed.
Patches Users are advised to upgrade to n8n version 1.120.3 or later, which fully resolves the issue.
As a general security best practice, n8n instance owners should ensure that: - Administrative access is limited to trusted users only. - Community packages are installed only from trusted sources. - Instances are kept up to date with the latest security releases.
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 issues have been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of these versions or later to remediate all known vulnerabilities.
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
Impact An authenticated user with permission to create or modify workflows could use the Merge node's "Combine by SQL" mode to read local files on the n8n host and achieve remote code execution. The AlaSQL sandbox did not sufficiently restrict certain SQL statements, allowing an attacker to access sensitive files on the server or even compromise the intance.
Patches The issue has been fixed in n8n versions 2.14.1, 2.13.3, and 1.123.27. Users should upgrade to one of 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. - Disable the Merge node by adding n8n-nodes-base.merge to the NODESEXCLUDE environment variable.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact An authenticated user with permission to create or modify workflows could exploit a prototype pollution vulnerability in the GSuiteAdmin node. By supplying a crafted parameter as part of node configuration, an attacker could write attacker-controlled values onto Object.prototype. An attacker could use this prototype pollution to achieve remote code execution on the n8n instance.
Patches The issue has been fixed in n8n versions 2.14.1, 2.13.3, and 1.123.27. Users should upgrade to one of 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. - Disable the XML node by adding n8n-nodes-base.xml to the NODESEXCLUDE environment variable.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact A flaw in the xml2js library used to parse XML request bodies in n8n's webhook handler allowed prototype pollution via a crafted XML payload. An authenticated user with permission to create or modify workflows could exploit this to pollute the JavaScript object prototype and, by chaining the pollution with the Git node's SSH operations, achieve remote code execution on the n8n host.
Patches The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of 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.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact An authenticated user with permission to create or modify workflows could achieve global prototype pollution via the XML Node leading to RCE when combined with other nodes exploiting the prototype pollution.
Patches The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of 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. - Disable the XML node by adding n8n-nodes-base.xml to the NODESEXCLUDE environment variable.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact An authenticated user with permission to create or modify workflows could bypass the patch for GHSA-hqr4-h3xv-9m3r in the XML node. When combined with other nodes, this could lead to RCE on the n8n host.
Patches The issue has been fixed in n8n versions 1.123.43, 2.20.7, and 2.22.1. Users should upgrade to one of 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. - Disable the XML node by adding n8n-nodes-base.xml to the NODESEXCLUDE environment variable.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
--- n8n has adopted CVSS 4.0 as primary score for all security advisories. CVSS 3.1 vector strings are provided for backwards compatibility.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Impact An authenticated user with permission to create or modify workflows could achieve global prototype pollution via an unvalidated pagination parameter in the HTTP Request node. Combined with other techniques this could lead to RCE on the instance.
Patches The issue has been fixed in n8n versions 1.123.43, 2.20.7, and 2.22.1. Users should upgrade to one of 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. - Disable the HTTP Request node by adding n8n-nodes-base.httpRequest to the NODESEXCLUDE environment variable.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
--- n8n has adopted CVSS 4.0 as primary score for all security advisories. CVSS 3.1 vector strings are provided for backwards compatibility.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Impact An authenticated user with permission to create or modify workflows could inject CLI flags on the Git node's Push operation allowing an attacker to read arbitrary files from the n8n server potentially leading to full compromise.
Patches The issue has been fixed in n8n versions 1.123.43, 2.20.7, and 2.22.1. Users should upgrade to one of 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. - Disable the Git node by adding n8n-nodes-base.git to the NODESEXCLUDE environment variable.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
--- n8n has adopted CVSS 4.0 as primary score for all security advisories. CVSS 3.1 vector strings are provided for backwards compatibility.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
n8n-workflows Main Commit ee25413 allows attackers to execute a directory traversal via the downloadworkflow function within apiserver.py
Impact An authenticated user with permission to create or modify workflows could chain the Read/Write Files from Disk node with git operations to achieve remote code execution. By writing to specific configuration files and then triggering a git operation, the attacker could execute arbitrary shell commands on the n8n host.
Patches The issue has been fixed in n8n versions 2.2.0 and 1.123.8. Users should upgrade to one of 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. - Disable the Read/Write Files from Disk node by adding n8n-nodes-base.readWriteFile to the NODESEXCLUDE environment variable.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact An attacker with write access to the git repository connected to an n8n Source Control configuration could commit a malicious Data Table JSON file containing a crafted column name. When an administrator performed a Source Control Pull, n8n imported the file and could lead to SQL injection on the internal PostgreSQL instance.
Exploitation requires all of the following conditions: - The n8n instance uses PostgreSQL as its database backend. - The Source Control feature is enabled and connected to a repository the attacker can write to. - An administrator triggers a Source Control Pull.
Patches The issue has been fixed in n8n version 1.123.43, 2.20.7, and 2.21.1. Users should upgrade to this version or later to remediate the vulnerability.
Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Disable the Source Control feature if it is not actively required. - Restrict write access to the connected git repository to fully trusted users only. - Avoid pulling from repositories that may have been modified by untrusted parties.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact Three EE endpoints used by the Dynamic Credentials feature accepted any authenticated n8n session without performing per-resource ownership or scope checks on the target workflow or credential. An authenticated user with no project membership or credential sharing relationship could enumerate credential identifiers, names, and types referenced by any private workflow in the instance, initiate an OAuth authorization flow against another user's credential to overwrite its stored tokens with tokens bound to an account they control, or revoke another user's stored credential tokens entirely.
Workflows relying on a hijacked credential would subsequently execute under the attacker's OAuth identity, enabling data exfiltration to attacker-controlled external services and persistent takeover of integrations. Token revocation would break affected workflows.
This issue only affects Enterprise instances where the Dynamic Credentials feature is enabled.
Patches The issue has been fixed in n8n versions 1.123.55, 2.25.7, and 2.26.2. Users should upgrade to one of these versions or later to remediate the vulnerability.
Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict n8n instance access to fully trusted users only. - If the Dynamic Credentials feature is not actively required, disable it by unsetting N8NENVFEATDYNAMICCREDENTIALS.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact The legacy expression evaluator's computed-member sanitizer can be bypassed by an authenticated user with workflow create or modify permissions. Successful exploitation grants the attacker host-level code execution as the n8n process.
The legacy expression engine is the default engine in affected versions.
Patches The issue has been fixed in n8n versions 1.123.64, 2.29.8, and 2.30.1. Users should upgrade to one of these versions or later to remediate the vulnerability.
Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict n8n instance access to fully trusted users only. - Switch to the non-legacy expression engine by setting N8NEXPRESSIONENGINE=vm.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.