Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
155 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact 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. 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: - Limit workflow creation and editing permissions to fully trusted users only.…
Recommended action: Upgrade to 2.14.1, 2.13.3 or 1.123.27 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.14.1, 2.13.3 or 1.123.26 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.14.1, 2.13.3 or 1.123.27 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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). Patches The issue has been fixed in n8n version 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: - Disable the Source Control feature if it is not actively required. - Restrict network access to ensure the n8n instance communicates with the Git server only over trusted, controlled network paths. These workarounds do…
Recommended action: Upgrade to 2.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated user without permission to list external secrets could reference a secret by the external name in a credential and retrieve its plaintext value when saving the credential. This bypassed the externalSecret:list permission check and allowed access to secrets stored in connected vaults without admin or owner privileges. - This issue requires the instance to have an external secrets vault configured. - The attacker must know or be able to guess the name of a target secret. Patches The issue has been fixed in n8n versions 1.123.23 and 2.6.4. 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 access to fully trusted users only. - Disable external secrets integration until the patch can be applied. These workarounds do not fully remediate the risk and should only be used as short-term mitigation…
Recommended action: Upgrade to 2.6.4 or 1.123.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.…
Recommended action: Upgrade to 2.4.0 or 1.121.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.…
Recommended action: Upgrade to 2.14.1, 2.13.3 or 1.123.27 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.14.1, 2.13.3 or 1.123.27 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated user with permission to create or modify workflows could use the JavaScript Task Runner to allocate uninitialized memory buffers. Uninitialized buffers may contain residual data from the same Node.js process — including data from prior requests, tasks, secrets, or tokens — resulting in information disclosure of sensitive in-process data. - Task Runners must be enabled using N8NRUNNERSENABLED=true. - In external runner mode, the impact is limited to data within the external runner process. Patches The issue has been fixed in n8n versions = 1.123.22, = 2.10.1 , and = 2.9.3. 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. - Use external runner mode (N8NRUNNERSMODE=external) to isolate the runner process. These workarounds do not fully…
Recommended action: Upgrade to 2.10.1, 2.9.3 or 1.123.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker who knows the webhook URL of a workflow using the ZendeskTrigger node could send unsigned POST requests and trigger the workflow with arbitrary data. The node does not verify the HMAC-SHA256 signature that Zendesk attaches to every outbound webhook, allowing any party to inject crafted payloads into the connected workflow. Patches The issue has been fixed in n8n versions 2.6.2 and 1.123.18. 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. - Restrict network access to the n8n webhook endpoint to known Zendesk IP ranges. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.6.2 or 1.123.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An end user interacting with a workflow that uses the Guardrail node could craft an input that bypasses the default guardrail instructions. Patches The issue has been fixed in n8n version 2.10.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 access to trusted users. - Review asses the practical impact of guardrail bypasses in your usecase and adjust your workflow accordingly. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When the Chat Trigger node is configured with n8n User Auth authentication, the authentication check could be circumvented. - This issue requires the Chat Trigger node to be configured with n8n User Auth authentication (non-default). 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 a different authentication method for the Chat Trigger node, or restrict network access to the webhook endpoint to trusted origins. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.10.1, 2.9.3 or 1.123.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated user signed in through Single Sign-On (SSO) could disable SSO enforcement for their own account through the n8n API. This allowed the user to create a local password and authenticate directly with email and password, completely bypassing the organization's SSO policy, centralized identity management, and any identity-provider-enforced multi-factor authentication. 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: - Monitor audit logs for users who create local credentials after authenticating via SSO. - Restrict 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.
Recommended action: Upgrade to 2.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker who knows the webhook URL of a workflow using the GitHub Webhook Trigger node could send unsigned POST requests and trigger the workflow with arbitrary data. The node did not implement the HMAC-SHA256 signature verification that GitHub provides to authenticate webhook deliveries, allowing any party to spoof GitHub webhook events. Patches The issue has been fixed in n8n versions 2.5.0 and 1.123.15. 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. - Restrict network access to the n8n webhook endpoint to known GitHub webhook IP ranges. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.5.0 or 1.123.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated user with permission to create or modify workflows and access to a database credential could unknowingly create a workflow that was vulnerable to SQL injection, even while expecting inputs to be handled safely through escaped parameters. By supplying specially crafted table or column names, an attacker could inject arbitrary SQL because the MySQL, PostgreSQL, and Microsoft SQL nodes did not escape identifier values when constructing queries, enabling injection through node configuration parameters. Patches The issue has been fixed in n8n version 2.4.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 the MySQL, PostgreSQL, and Microsoft SQL nodes by adding n8n-nodes-base.mySql, n8n-nodes-base.postgres, and…
Recommended action: Upgrade to 2.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.10.1, 2.9.3 or 1.123.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 -…
Recommended action: Upgrade to 2.10.1, 2.9.3 or 1.123.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.2.0 or 1.123.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.10.1, 2.9.3 or 1.123.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.10.1, 2.9.3 or 1.123.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.10.1, 2.9.3 or 1.123.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: =<h2Thank you, {{ $input.first().json[\"Name\"] }}!</h2 There is no practical reason for a workflow designer to prefix a field with = intentionally — the character is…
Recommended action: Upgrade to 2.10.1, 2.9.3 or 1.123.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches This issue is fixed in version 1.121.0 and later. All users are strongly encouraged to upgrade. Workarounds Until projects can upgrade: - Replace wildcard domain patterns with explicit domain listings in HTTP Request credentials - Review and restrict workflow creation/modification permissions to trusted users only - Audit existing workflows using HTTP Request nodes with domain-restricted credentials --- 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:U/C:H/I:N/A:N
Recommended action: Upgrade to 1.121.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.4.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.