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 containing a Python Code Node could escape the sandbox and achieve arbitrary code execution on the task runner container. This issue only affects instances where the Python Task Runner is enabled. Patches The issue has been fixed in n8n versions 1.123.48, 2.21.8, and 2.22.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: - Limit workflow creation and editing permissions to fully trusted users only. - Disable the Python Code node by adding n8n-nodes-base.code to the NODESEXCLUDE environment variable, or disable the Python Task Runner entirely. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.22.4, 2.21.8 or 1.123.48 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The POST /rest/dynamic-node-parameters/options endpoint allowed any authenticated user to cause the n8n server to issue HTTP requests including credentials bypassing the intended restrictions on which hosts could be contacted for that credential (Allowed HTTP Request Domains). The user needed to be authenticated and have access to the credential. Patches The issue has been fixed in n8n version 2.20.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: - Restrict n8n access to fully trusted users only. - Limit credential sharing to users who genuinely require access to those credentials. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.20.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The ExecuteWorkflow node's localFile source option read workflow files from disk without applying checks enforced by other file-reading nodes. An authenticated user with permission to create or modify workflows could supply an arbitrary file path via the REST API, bypassing the N8NRESTRICTFILEACCESSTO restriction. This allowed the attacker to determine whether arbitrary files exist on the server host. Where the targeted path contained a valid workflow JSON file, the file could additionally be loaded and executed, potentially triggering actions on downstream systems connected to that workflow. The localFile source option is hidden from the n8n UI since v1.2 but remains accessible via the REST API. Patches The issue has been fixed in n8n version 2.20.0 or 2.19.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: - Restrict workflow…
Recommended action: Upgrade to 2.19.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.21.1, 2.20.7 or 1.123.43 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 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…
Recommended action: Upgrade to 2.21.1, 2.20.7 or 1.123.43 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 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
Recommended action: Upgrade to 2.22.1, 2.20.7 or 1.123.43 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 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
Recommended action: Upgrade to 2.22.1, 2.20.7 or 1.123.43 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 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.…
Recommended action: Upgrade to 2.22.1, 2.20.7 or 1.123.43 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 achieve global prototype pollution via the XML Node leading to RCE when combined with other nodes exploiting the prototype pollution. Patches The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Limit workflow creation and editing permissions to fully trusted users only. - Disable the XML node by adding n8n-nodes-base.xml to the NODESEXCLUDE environment variable. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.18.1, 2.17.4 or 1.123.32 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 flaw in the xml2js library used to parse XML request bodies in n8n's webhook handler allowed prototype pollution via a crafted XML payload. An authenticated user with permission to create or modify workflows could exploit this to pollute the JavaScript object prototype and, by chaining the pollution with the Git node's SSH operations, achieve remote code execution on the n8n host. Patches The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Limit workflow creation and editing permissions to fully trusted users only. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures. --- n8n has adopted CVSS 4.0 as primary score for all security advisories. CVSS 3.1 vector strings are provided for backwards…
Recommended action: Upgrade to 2.18.1, 2.17.4 or 1.123.32 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 unauthenticated attacker could register a malicious MCP OAuth client with a crafted clientname. If a victim user authorized the OAuth consent dialog and a second user subsequently revoked that access, a toast notification would render the injected script. Clicking the link would execute arbitrary JavaScript in the victim's authenticated n8n browser session, enabling credential and session token theft, workflow manipulation, or privilege escalation. Patches This issue has been fixed in n8n version 2.14.2. 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: - Restrict access to the n8n instance and the MCP OAuth registration endpoint to trusted users only. - Disable MCP server functionality if it is not actively required. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.18.1, 2.17.4 or 1.123.32 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches The issue has been fixed in n8n version 2.18.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: - Restrict n8n…
Recommended action: Upgrade to 2.17.5 or 1.123.33 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 containing a Python Code Node could escape the sandbox and achieve arbitrary code execution on the task runner container. - This issue only affects instances where the Python Task Runner is enabled. Patches The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Limit workflow creation and editing permissions to fully trusted users only. - Disable the Python Code node by adding n8n-nodes-base.code to the NODESEXCLUDE environment variable, or disable the Python Task Runner entirely. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.18.1, 2.17.4 or 1.123.32 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 a valid API key scoped to variable:list could read variables from projects they are not a member of by supplying an arbitrary projectId query parameter to the public API variables endpoint. The handler queried the variables repository directly without enforcing project membership checks, bypassing the authorization-aware service layer used by the internal enterprise controller. If variables were misused to store sensitive information such as credentials or tokens, they should be rotated immediately. This issue only affects licensed enterprise or team deployments with multiple projects and the variables feature enabled. Patches The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict n8n access and API key issuance to…
Recommended action: Upgrade to 2.18.1, 2.17.4 or 1.123.32 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The MCP OAuth client registration endpoint accepted unauthenticated requests and stored client data without adequate resource controls. An unauthenticated remote attacker could exhaust server memory resources by sending large registration payloads, rendering the n8n instance unavailable. The MCP enable/disable toggle gates MCP access but did not restrict client registrations, meaning the endpoint is reachable regardless of whether MCP access is enabled on the instance. The patches address the unbound registration with an upper bound of registered clients and disabling creation when MCP is disabled on the instance. Mean to restrict the payload size of requests already exist and can be used to control additional risks. Patches The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following…
Recommended action: Upgrade to 2.18.1, 2.17.4 or 1.123.32 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Exploitation requires the following conditions: - The instance exposes a public Hosted Chat workflow with authentication set to None. - A target execution is in a waiting state at the time of the attack. - The attacker can obtain or discover the execution ID of that waiting execution. Patches The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should…
Recommended action: Upgrade to 2.18.1, 2.17.4 or 1.123.32 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 flaw in the SeaTable node's row:search and row:get operations allowed user-controlled input to be concatenated directly into SQL query strings without escaping or parameterization. In workflows where external user input is passed via expressions into the SeaTable node's search or row retrieval parameters, an attacker could manipulate the constructed query to retrieve unintended rows from the connected SeaTable base, bypassing row-level filtering logic implemented in the workflow. Exploitation requires a specific workflow configuration: - The SeaTable node must be used with user-controlled input passed via expressions (e.g., from a form or webhook) into the searchTerm or rowId parameters. Patches The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: -…
Recommended action: Upgrade to 2.18.1, 2.17.4 or 1.123.32 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The /mcp-oauth/register endpoint accepted OAuth client registrations without authentication, allowing arbitrary redirecturi values to be registered. When a user denies the MCP OAuth consent dialog, the handleDeny handler redirects the user to the registered redirecturi without validation, enabling an open redirect to an attacker-controlled URL. An attacker can craft a phishing link and send it to a victim; if the victim clicks "Deny" on the consent page, they are silently redirected to an external site. Patches The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict network access to the n8n instance to prevent untrusted users from reaching the MCP OAuth endpoints. - Limit access to the n8n instance to fully trusted users only. These workarounds…
Recommended action: Upgrade to 2.18.1, 2.17.4 or 1.123.32 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 flaw in the Oracle Database node's select operation allowed user-controlled input passed into the Limit field via expressions to be interpolated directly into the SQL query without sanitization or parameterization. In workflows where external input is passed into the Limit field (e.g., from a webhook), an attacker could inject arbitrary SQL and exfiltrate data from the connected Oracle database. Exploitation requires a specific workflow configuration: - The Oracle Database node must be used with user-controlled input passed via expressions into the Limit field. - Authentication requirements depend on the workflow's configuration (e.g., an unauthenticated webhook endpoint would allow unauthenticated exploitation). Patches The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following…
Recommended action: Upgrade to 2.18.1, 2.17.4 or 1.123.32 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The fix for GHSA-f3f2-mcxc-pwjx did not cover the Snowflake node or the legacy MySQL v1 node. Both nodes construct SQL queries by directly interpolating user-controlled table names, column names, and update keys into query strings without identifier escaping, enabling SQL injection against the connected database. Exploitation requires a specific workflow configuration: - The Snowflake or MySQL v1 node must be used with user-controlled input passed via expressions (e.g., from a form or webhook) into identifier fields such as table name, column name, or update key. Successful exploitation could allow data exfiltration, modification, or deletion on the downstream database. Patches The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Limit workflow…
Recommended action: Upgrade to 2.18.1, 2.17.4 or 1.123.32 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 and share credentials could craft a malicious OAuth2 credential containing a JavaScript URL in the Authorization URL field. If a victim opened the credential and interacted with the OAuth authorization button, the injected script would execute in their browser session. Patches The issue has been fixed in n8n versions 2.8.0 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: - Limit credential creation and sharing permissions to fully trusted users only. - Restrict access to the n8n instance to 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 2.6.4 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 inject malicious JavaScript into the Custom CSS field of the Chat Trigger node. Due to a misconfiguration in the sanitize-html library, the sanitization could be bypassed, resulting in stored XSS on the public chat page. Any user visiting the chat URL would be affected. 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. - Disable the Chat Trigger node by adding @n8n/n8n-nodes-langchain.chatTrigger 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 configure a Form Node with an unsanitized HTML description field or exploit an overly permissive iframe sandbox policy to perform stored cross-site scripting or redirect end users visiting the form to an arbitrary external URL. The vulnerability could be used to facilitate phishing attacks. Patches The issue has been fixed in n8n versions 1.123.24, 2.10.4 and 2.12.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: - Limit workflow creation and editing permissions to fully trusted users only. - 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…
Recommended action: Upgrade to 2.12.0, 2.10.4 or 1.123.24 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 flaw in the Form Trigger node's CSS sanitization to store a cross-site scripting (XSS) payload. The injected script executes persistently for every visitor of the published form, enabling form submission hijacking and phishing. The existing Content Security Policy prevents direct n8n session cookie theft but does not prevent script execution or form action manipulation. Patches The issue has been fixed in n8n versions 2.12.0, 2.11.2, and 1.123.25. 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 Form Trigger node by adding n8n-nodes-base.formTrigger to the NODESEXCLUDE environment variable. These workarounds do not fully remediate the risk and…
Recommended action: Upgrade to 2.11.2 or 1.123.25 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 flaw in the LDAP node's filter escape logic allowed LDAP metacharacters to pass through unescaped when user-controlled input was interpolated into LDAP search filters. In workflows where external user input is passed via expressions into the LDAP node's search parameters, an attacker could manipulate the constructed filter to retrieve unintended LDAP records or bypass authentication checks implemented in the workflow. Exploitation requires a specific workflow configuration: - The LDAP node must be used with user-controlled input passed via expressions (e.g., from a form or webhook). 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. - Disable the LDAP node by…
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.