n8n is an open source workflow automation platform. Prior to versions 1.123.32, 2.17.4, and 2.18.1, the /chat WebSocket endpoint used by the Chat Trigger node's Hosted Chat feature did not verify that an incoming connection was authorized to interact with the target execution. An unauthenticated remote attacker who could identify a valid execution ID for a workflow in a waiting state could attach to that execution, receive the pending prompt intended for the legitimate user, and submit arbitrary input to resume or influence downstream workflow behavior. This issue has been patched in versions 1.123.32, 2.17.4, and 2.18.1.
n8n is an open source workflow automation platform. Prior to versions 1.123.33 and 2.17.5, the dynamic-node-parameters endpoints did not verify whether the authenticated caller was authorized to use a supplied credential reference. An authenticated user with access to a shared workflow could supply a foreign credential ID in the request body, causing the backend to decrypt and use that credential in a helper execution path where the caller also controls the destination URL. This allowed the caller to force the backend to authenticate against attacker-controlled infrastructure using a credential belonging to another user, effectively exfiltrating a reusable API key. The issue is not limited to any single node type; any node that resolves credentials dynamically through these endpoints may be affected. This issue has been patched in versions 1.123.33, 2.17.5, and 2.18.0.
n8n is an open source workflow automation platform. Prior to versions 1.123.27, 2.13.3, and 2.14.1, an authenticated user with permission to create or modify workflows could craft a workflow that produces an HTML binary data object without a filename. The `/rest/binary-data` endpoint served such responses inline on the n8n origin without `Content-Disposition` or `Content-Security-Policy` headers, allowing the HTML to render in the browser with full same-origin JavaScript access. By sending the resulting URL to a higher-privileged user, an attacker could execute JavaScript in the victim's authenticated session, enabling exfiltration of workflows and credentials, modification of workflows, or privilege escalation to admin. 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. If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Limit workflow creation and editing permissions to fully trusted users only, and/or restrict network access to the n8n instance to prevent untrusted users from accessing binary data URLs. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
n8n is an open source workflow automation platform. Prior to version 2.5.0, when the Source Control feature is configured to use SSH, the SSH command used for git operations explicitly disabled host key verification. A network attacker positioned between the n8n instance and the remote Git server could intercept the connection and present a fraudulent host key, potentially injecting malicious content into workflows or intercepting repository data. This issue only affects instances where the Source Control feature has been explicitly enabled and configured to use SSH (non-default). The issue has been fixed in n8n version 2.5.0. Users should upgrade to this version or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Disable the Source Control feature if it is not actively required, and/or restrict network access to ensure the n8n instance communicates with the Git server only over trusted, controlled network paths. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
n8n versions prior to 1.123.23 and 2.6.4 contain an authorization bypass vulnerability that allows authenticated users without the externalSecret:list permission to retrieve plaintext secrets from connected external vaults by referencing the secret name in credentials. This vulnerability requires the instance to have an external secrets vault configured and the attacker to know or guess the secret's name. The issue has been fixed in versions 1.123.23 and 2.6.
n8n is an open source workflow automation platform. Prior to version 2.8.0, when the `N8N_SKIP_AUTH_ON_OAUTH_CALLBACK` 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 `N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=true` is explicitly configured (non-default). The issue has been fixed in n8n version 2.8.0. Users should upgrade to this version or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Avoid enabling `N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=true` unless strictly required, and/ or 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.
n8n is an open source workflow automation platform. Prior to versions 2.14.1, 2.13.3, and 1.123.26, 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. 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. 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 `NODES_EXCLUDE` environment variable, and/or 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 versions prior to 2.4.0 and 1.121.0 contain an improper authentication vulnerability when LDAP authentication is enabled. An authenticated LDAP user who can modify their own LDAP email attribute could impersonate another user, including administrators, by matching their email, resulting in permanent account takeover. This occurs because n8n automatically links LDAP identities to existing local accounts based on email attribute matching, and the linkage persists even if the LDAP email is reverted. The vulnerability requires LDAP authentication to be configured and active. It has been fixed in n8n versions 2.4.
n8n is an open source workflow automation platform. Prior to versions 2.14.1, 2.13.3, and 1.123.27, 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. 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. If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Restrict instance access to fully trusted users only, and/or 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.
n8n is an open source workflow automation platform. Prior to versions 2.10.1, 2.9.3, and 1.123.22, 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. 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. If upgrading is not immediately possible, administrators should consider the following temporary mitigations. Limit workflow creation and editing permissions to fully trusted users only, and/or 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.
n8n is an open source workflow automation platform. Prior to versions 2.10.1, 2.9.3, and 1.123.22, 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 `N8N_RUNNERS_ENABLED=true`. 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. If upgrading is not immediately possible, administrators should consider the following temporary mitigations. Limit workflow creation and editing permissions to fully trusted users only., and/or disable the Code node by adding `n8n-nodes-base.code` to the `NODES_EXCLUDE` environment variable. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
n8n is an open source workflow automation platform. Prior to 1.121.0, there is a vulnerability in the HTTP Request node's credential domain validation allowed an authenticated attacker to send requests with credentials to unintended domains, potentially leading to credential exfiltration. This only might affect user who have credentials that use wildcard domain patterns (e.g., *.example.com) in the "Allowed domains" setting. This issue is fixed in version 1.121.0 and later.
n8n is an open source workflow automation platform. From version 0.187.0 to before 1.120.3, 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. This issue has been patched in version 1.120.3.
CVE-2026-25054 is a high-severity Cross-Site Scripting (XSS) vulnerability in the n8n open source workflow automation platform, affecting versions prior to 1.123.9 and 2.2.1. The flaw exists in a markdown rendering component used in the user interface, including workflow sticky notes and other markdown-supported areas. An authenticated user with workflow creation or modification permissions can inject malicious scripts that execute with same-origin privileges when other users view the crafted workflows. This can lead to session hijacking and account takeover. The vulnerability requires authentication and some user interaction but does not require elevated privileges beyond workflow modification rights. No known exploits are currently reported in the wild.
CVE-2026-25052 is a critical TOCTOU race condition vulnerability in the n8n workflow automation platform prior to versions 1.123.18 and 2.5.0. Authenticated users with workflow creation or modification permissions can exploit this flaw to bypass file access controls and read sensitive files on the host system. This exposure can lead to disclosure of critical configuration data and user credentials, enabling complete account takeover of any user on the affected instance. The vulnerability requires low privileges but no user interaction and can be exploited remotely. Although no known exploits are reported in the wild yet, the high CVSS score of 9.4 reflects its severe impact on confidentiality, integrity, and availability.
CVE-2026-25051 is a high-severity Cross-Site Scripting (XSS) vulnerability in the open-source workflow automation platform n8n prior to version 1.123.2. It arises from improper input neutralization in webhook responses and related HTTP endpoints, where the Content Security Policy sandbox is sometimes not correctly applied. An authenticated user with workflow creation or modification permissions can exploit this to execute malicious scripts with same-origin privileges when other users interact with the crafted workflow. This can lead to session hijacking and account takeover. The vulnerability requires authenticated access and some user interaction but does not require elevated privileges beyond workflow modification rights. No known exploits are currently reported in the wild. The issue has been patched in version 1.123.
CVE-2025-61917 is a high-severity vulnerability in the n8n workflow automation platform versions 1.65.0 through before 1.114.3. It arises from the unsafe use of Buffer.allocUnsafe() and Buffer.allocUnsafeSlow() in the task runner, which can lead to allocation of uninitialized memory buffers. These buffers may contain residual sensitive data such as secrets, tokens, or data from prior tasks within the same Node.js process, resulting in potential information disclosure.
CVE-2026-25049 is a critical vulnerability in the n8n workflow automation platform affecting versions prior to 1.123.17 and 2.5.2. Authenticated users with permissions to create or modify workflows can exploit crafted expressions in workflow parameters to execute arbitrary system commands on the host running n8n. This vulnerability arises from improper control of dynamically-managed code resources (CWE-913). No user interaction is required beyond authentication, and the exploit can lead to full system compromise. The issue has been patched in the specified versions. Although no known exploits are currently reported in the wild, the high CVSS score of 9.
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.
CVE-2025-68949 is a medium-severity vulnerability in the n8n workflow automation platform versions 1.36.0 up to but not including 2.2.0. The flaw lies in the Webhook node’s IP whitelist validation, which uses partial string matching instead of exact IP comparison. This allows an attacker with a non-whitelisted IP address that shares a substring with a trusted IP to bypass IP-based access controls and invoke restricted webhooks. Both IPv4 and IPv6 addresses are affected. The vulnerability does not require authentication or user interaction and impacts confidentiality by potentially exposing restricted workflows. The issue is fixed in version 2.