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.

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

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

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 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 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

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.

Impact A TOCTOU race condition in the Git node's clone operation lets an authenticated user bypass its path restrictions by swapping a directory for a symlink after the path is validated but before the clone runs. This plants a crafted repository in the community node directory, which n8n loads as a custom node on the next restart, and since nodes execute JavaScript, this yields arbitrary code execution on the server.

Both self-hosted and cloud instances are affected, where authenticated users can create and run workflows using the Git node.

Patches Users should upgrade to the patched version once available 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. - Disable the Git node by adding n8n-nodes-base.git to the NODESEXCLUDE environment variable. - Restrict network egress from the n8n instance to prevent connections to attacker-controlled git repositories.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact When LDAP authentication is enabled, n8n automatically linked an LDAP identity to an existing local account if the LDAP email attribute matched the local account's email. An authenticated LDAP user who could control their own LDAP email attribute could set it to match another user's email — including an administrator's — and upon login gain full access to that account. The account linkage persisted even if the LDAP email was later reverted, resulting in a permanent account takeover.

- LDAP authentication must be configured and active (non-default).

Patches The issue has been fixed in n8n versions 2.4.0 and 1.121.0. 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: - Disable LDAP authentication until the instance can be upgraded. - Restrict LDAP directory permissions so that users cannot modify their own email attributes. - Audit existing LDAP-linked accounts for unexpected account associations.

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 SQL injection vulnerability in the Data Table Get node. On default SQLite DB, single statements can be manipulated and the attack surface is practically limited. On PostgreSQL deployments, multi-statement execution is possible, enabling data modification and deletion.

Patches The issue has been fixed in n8n versions 1.123.26, 2.13.3, and 2.14.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 Data Table node by adding n8n-nodes-base.dataTable to the NODESEXCLUDE environment variable. - Review existing workflows for Data Table Get nodes where orderByColumn is set to an expression that incorporates external or user-supplied input.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

n8n before 1.123.69, 2.x before 2.33.4, and 2.34.x before 2.34.1 contain an arbitrary file read and write vulnerability in the Snowflake node, which passes free-form Execute Query input, including client-side commands, directly to the Snowflake SDK without applying n8n's file-access restrictions. An authenticated user with usable Snowflake credentials can upload a local file from the n8n host or overwrite an existing file with a staged one.

Impact A Cross-site Scripting (XSS) vulnerability existed in a markdown rendering component used in n8n's interface, including workflow sticky notes and other areas that support markdown content.

An authenticated user with permission to create or modify workflows could abuse this to execute scripts with same-origin privileges when other users interact with a maliciously crafted workflow. This could lead to session hijacking and account takeover.

Patches The issue has been fixed in n8n versions 2.2.1 and 1.123.9. 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. - Review existing workflows for potentially malicious markdown content in sticky notes and other components. - Educate users about the risks of opening workflows from untrusted sources. 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 backward compatibility.

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N

Impact An authenticated user with permission to create or modify workflows could inject arbitrary scripts into pages rendered by the n8n application using different techniques on various nodes (Form Trigger node, Chat Trigger node, Send & Wait node, Webhook Node, and Chat Node). Scripts injected by a malicious workflow execute in the browser of any user who visits the affected page, enabling session hijacking and account takeover.

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 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 Webhook node by adding n8n-nodes-base.webhook to the NODESEXCLUDE environment variable.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Credit Reporters: - @ori-ron - @Aikido-Security - @nil340 - Pawel Bednarz from the NATO Cyber Security Centre (NCSC)

Impact An authenticated user with the global:member role could exploit chained authorization flaws in n8n's credential pipeline to steal plaintext secrets from generic HTTP credentials (httpBasicAuth, httpHeaderAuth, httpQueryAuth) belonging to other users on the same instance.

The attack abuses a name-based credential resolution path that does not enforce ownership or project scope, combined with a bypass in the credentials permission checker that causes generic HTTP credential types to be skipped during pre-execution validation. Together, these flaws allow a member-role user to resolve another user's credential ID and execute a workflow that decrypts and uses that credential without authorization.

Native integration credential types (e.g. slackApi, openAiApi, postgres) are not affected by this issue.

This vulnerability affects Community Edition only. Enterprise Edition has additional permission gates on workflow creation and execution that independently block this attack chain.

Patches The issue has been fixed in n8n versions 1.123.27, 2.13.3, and 2.14.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 instance access to fully trusted users only. - Audit credentials stored on the instance and rotate any generic HTTP credentials (httpBasicAuth, httpHeaderAuth, httpQueryAuth) that may have been exposed.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact A member-level user with editor access to a shared workflow could reference credentials they do not own via specific public API endpoints. Credential ownership checks were only enforced partially leading to cross-user credential access.

This issue affects instances where workflow sharing is enabled and at least one workflow has been shared with a member-level user as an Editor.

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 workflow sharing to fully trusted users only. - Audit shared workflows for unexpected credential references or recent modifications.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Credits: Momen Elkhouli

Impact The Resource Locator passes the workflow-persisted cachedResultUrl to window.open() without scheme validation. When a victim opens the crafted workflow and interact with external links, the JavaScript payload runs in the victim's browser.

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 workflow creation and editing permissions to fully trusted users only. - Audit existing workflows for unexpected cachedResultUrl values containing non-HTTP(S) schemes.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact The OAuth1 and OAuth2 credential reconnect endpoints authorized access using credential:read rather than credential:update. An authenticated user with read-only access to a shared credential could initiate an OAuth reconnect flow and overwrite the stored token material for that credential with tokens bound to an external account they control. Workflows relying on the affected credential would subsequently execute under the attacker's OAuth identity, enabling data exfiltration to attacker-controlled external services and persistent takeover of shared integrations.

This issue affects instances where credentials are shared with other users or across projects.

Patches The issue has been fixed in n8n versions 1.123.43, 2.20.7, and 2.21.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 credential sharing to fully trusted users only. - Audit shared credentials for unexpected OAuth token changes and revoke any tokens that may have been replaced.

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:N/I:H/A:N