Impact When the N8NSKIPAUTHONOAUTHCALLBACK environment variable is set to true, the OAuth callback handler skips ownership verification of the OAuth state parameter. This allows an attacker to trick a victim into completing an OAuth flow against a credential object the attacker controls, causing the victim's OAuth tokens to be stored in the attacker's credential. The attacker can then use those tokens to execute workflows in their name.
- This issue only affects instances where N8NSKIPAUTHONOAUTHCALLBACK=true is explicitly configured (non-default).
Patches The issue has been fixed in n8n version 2.8.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: - Avoid enabling N8NSKIPAUTHONOAUTHCALLBACK=true unless strictly required. - Restrict access to the n8n instance 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 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.
Analysis of two critical n8n workflow automation vulnerabilities enabling remote code execution, including a bypass of security mitigations.
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
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 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
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
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
A Cross-site Scripting (XSS) vulnerability has been identified in the handling of webhook responses and related HTTP endpoints. Under certain conditions, the Content Security Policy (CSP) sandbox protection intended to isolate HTML responses may not be applied correctly.
An authenticated user with permission to create or modify workflows could abuse this to execute malicious scripts with same-origin privileges when other users interact with the crafted workflow. This could lead to session hijacking and account takeover.
Patches
The issue has been fixed in n8n versions 1.122.5 and 1.123.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. - Never execute untrusted workflows. - Review workflows that receive data from via webhooks, forms, or MCP servers to ensure they are communicating with trusted entities before executing them manually.
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
The use of Buffer.allocUnsafe() and Buffer.allocUnsafeSlow() in the task runner allowed untrusted code to allocate uninitialized memory. Such uninitialized buffers could contain residual data from within the same Node.js process (for example, data from prior requests, tasks, secrets, or tokens), resulting in potential information disclosure.
Only authenticated users are able to execute code through Task Runners.
This issue affected any deployment in which both of the following conditions were met: - Task Runners were enabled using N8NRUNNERSENABLED=true (default: false) - Code Node was enabled (default: true)
Patches
Access to unsafe Buffer functions has been removed from the task runner sandbox. All buffer allocations are now zero-filled by default.
- Fixed in: 1.114.3 & 1.115.0 - Action: It is strongly recommended to upgrade to version ≥ 1.114.3 as soon as possible.
Changes introduced in this patch include: - Routing all buffer allocations through Buffer.alloc (which zero-fills) operations where applicable - Adding regression tests to ensure continued enforcement of safe allocation practices
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 for configuration details and required environment variables.
Resources
- Node.js documentation: Buffer.alloc() vs Buffer.allocUnsafe() — background on zero-filled vs uninitialized allocations - n8n Documentation — Task Runners — external mode, setup guide, and environment configuration details - n8n Documentation — Blocking nodes — how to globally disable specific nodes
I discovered a critical vulnerability (CVE-2026-21858, CVSS 10.0) in n8n that enables unauthorized attackers to take over locally deployed instances, impacting an estimated 100,000 servers globally. This vulnerability is a logical bug, which I call - a (Content-)Type Confusion. Let me know what you think!
A new critical vulnerability (CVE-2025-68613, CVSS 9.9) has been disclosed in n8n. It relates to the expression evaluation system, where insufficient isolation of the evaluation environment allows specially crafted workflow expressions to escape the expected execution context. This enables remote code execution in affected versions, potentially impacting data, workflow integrity, and the underlying host.
The issue spans from version 0.211.0 through patched versions 1.120.4, 1.121.1, and 1.122.0. n8n has already released patches, and updating is the recommended solution.
I developed a small scanner and a secure proof of concept (PoC) to check for vulnerable builds and observe the behavior of exposed metadata in affected instances. It does not exploit the remote code execution vulnerability and is designed for testing in controlled environments. I do not recommend running it in a development environment, as it may expose sensitive information such as IDs or keys.
The code is available here if anyone wants to explore it:
https://github.com/nehkark/CVE-2025-68613
Merry Christmas and Happy New Year
kkn
Anyone else noticing how supply-chain attacks are exploding? npm hijacks, zero-days, and now tools like n8n + agentic automation quietly pulling in risky deps with CVE-2025-68613 and remote code execution. Came across this guide which shows how to fix. Stay safe out there!
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.