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.
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.
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.
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 temporary mitigations: - Restrict network access to the n8n instance to prevent requests from untrusted sources. - Reduce the maximum accepted payload size by lowering the N8NPAYLOADSIZEMAX environment variable from its default value.
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 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.
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 consider the following temporary mitigations: - Enable authentication on all Chat Trigger nodes by setting the Authentication field to n8n User Auth rather than None.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
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 fully trusted users only. - Audit existing project variables for sensitive values and rotate any secrets that may have been exposed.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
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 creation and editing permissions to fully trusted users only. - Migrate workflows from the legacy MySQL v1 node to the MySQL v2 node, which already implements identifier escaping. - Disable the Snowflake node by adding n8n-nodes-base.snowflake to the NODESEXCLUDE environment variable. - Avoid passing unvalidated external user input into table name, column name, or update key fields via expressions in the affected nodes.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
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: - Limit workflow creation and editing permissions to fully trusted users only. - Disable the SeaTable node by adding n8n-nodes-base.seaTable to the NODESEXCLUDE environment variable. - Avoid passing unvalidated external user input into SeaTable node search or row retrieval parameters via expressions.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
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 temporary mitigations: - Limit workflow creation and editing permissions to fully trusted users only. - Disable the Oracle Database node by adding n8n-nodes-base.oracleDatabase to the NODESEXCLUDE environment variable. - Avoid passing unvalidated external user input into the Oracle Database node's Limit field via expressions.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
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 do not fully remediate the risk and should only be used as short-term mitigation measures.