n8n before 1.123.89, 2.x before 2.45.5, 2.46.x before 2.46.1, and 3.x before 3.0.1 bundles a GraphicsMagick version with known vulnerabilities in its official Docker image, which the Edit Image node uses to process images. Attackers who can supply crafted untrusted images to an Edit Image workflow, such as one fed by a Webhook node, can execute code on the n8n instance.

n8n before 2.46.1 contains a credential exposure vulnerability that forwards Authorization headers and basic auth credentials on cross-origin redirects because sendCredentialsOnCrossOriginRedirect defaults to true. Attackers controlling a redirect target or an expression-fed URL in credential-using nodes can capture stored workflow credentials sent to their endpoint.

n8n before 1.123.89 contains an insufficient isolation vulnerability in workflow expression evaluation that allows authenticated users to escape the sandbox. Attackers with permission to create or modify workflows can craft expressions referencing unexpected JavaScript properties to execute arbitrary code on the n8n host.

n8n before 2.46.1 contains an arbitrary file read vulnerability that allows authenticated members to read server files by supplying absolute paths to the Browser Use browserupload tool. Attackers with a connected remote browser session can have Playwright read files such as instance configuration from the n8n server and retrieve their contents from the page.

n8n before 1.123.89, 2.x before 2.45.5, 2.46.x before 2.46.1, and 3.x before 3.0.1 contains a NoSQL injection vulnerability in the MongoDB node's Update and Find And Replace operations due to insufficient validation of the update key value taken from incoming items. Attackers who can supply untrusted input, such as a webhook body, to a workflow using these operations can make the node match and overwrite unintended documents or insert new documents in the MongoDB database.

n8n before 1.123.89 contains an authentication bypass vulnerability in the Chat Trigger that allows unauthenticated attackers to skip n8n User Auth through the setup GET webhook route in embedded chat mode. Attackers can send unauthenticated GET requests to the chat webhook URL to read named session conversation history or trigger workflows with attacker-supplied input.

n8n before 1.123.89 contains a credential leakage vulnerability in the NocoDB node that sends the configured NocoDB API token to attacker-chosen hosts when downloading attachments. Attackers with write access to a NocoDB attachment cell can insert a URL to their host, capturing the API token when the workflow executes with Download Attachments enabled.

n8n before 2.38.0 and 3.x before 3.0.1 contains a missing authentication vulnerability in the Asana Trigger that accepts a new webhook verification secret from any request carrying an X-Hook-Secret header. Unauthenticated attackers who know the webhook URL can replace the secret, send forged Asana events that pass signature verification, and trigger workflows with attacker-controlled data while genuine deliveries are rejected.

n8n before 1.123.89, 2.x before 2.45.5, 2.46.x before 2.46.1, and 3.x before 3.0.1 contains an open redirect vulnerability in the unauthenticated MCP OAuth dynamic client registration flow, which accepts arbitrary redirecturi values via the /mcp-oauth/register endpoint. Attackers can send victims crafted /mcp-oauth/authorize URLs that redirect them to attacker-controlled sites before instance checks run, enabling phishing.

n8n before 2.45.5, 2.46.x before 2.46.1, and 3.x before 3.0.1 contains a flaw in the OAuth2 credential callback of the dynamic-credential connect flow, which does not verify that the completing browser belongs to the user who started the flow. Members with access to a resolvable OAuth2 credential can send the provider authorization URL to a victim; if the victim consents without an active n8n session, the victim's tokens are stored under the member's identity, letting the member's workflows act as the victim.

n8n before 2.43.5, 2.44.x before 2.44.1, and 3.x before 3.0.1 contains an SQL injection vulnerability in the Vector Store (OracleDB) node, which does not validate Metadata Filter keys used in vector search queries. Attackers can supply crafted filter keys through untrusted workflow input such as webhooks to read data accessible to the configured Oracle credential.

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 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 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.

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 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 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 access to fully trusted users only. - Avoid sharing workflows with users who should not have access to the credentials those workflows reference.

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 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 /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 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 authentication bypass in the Stripe Trigger node allows unauthenticated parties to trigger workflows by sending forged Stripe webhook events.

The Stripe Trigger creates and stores a Stripe webhook signing secret when registering the webhook endpoint, but incoming webhook requests were not verified against this secret. As a result, any HTTP client that knows the webhook URL could send a POST request containing a matching event type, causing the workflow to execute as if a legitimate Stripe event had been received.

This issue affects n8n users who have active workflows using the Stripe Trigger node. An attacker could potentially fake payment or subscription events and influence downstream workflow behavior. The practical risk is reduced by the fact that the webhook URL contains a high-entropy UUID; however, authenticated n8n users with access to the workflow can view this webhook ID.

Patches The issue has been fixed in n8n version 2.2.2. Users should upgrade to this version or later to ensure that Stripe webhook signatures are properly verified.

Workarounds There is no complete workaround short of upgrading. As a temporary mitigation, users can deactivate affected workflows or restrict access to workflows containing Stripe Trigger nodes to trusted users only.

An arbitrary file upload vulnerability in the Chat Trigger component of N8N v1.95.3, v1.100.1, and v1.101.1 allows attackers to execute arbitrary code via uploading a crafted HTML file.

n8n before 2.42.6, 2.43.x before 2.43.3, and 3.x before 3.0.1 contains a remote code execution vulnerability via deprecated Function, Function Item, and LangChain Code nodes running outside task runner isolation. Authenticated users who can create, modify, or import workflows naming these hidden node types can execute JavaScript in the n8n main process.

n8n before 2.42.6, 2.43.x before 2.43.3, and 3.x before 3.0.1 contains a remote code execution vulnerability via deprecated Function, Function Item, and LangChain Code nodes running outside task runner isolation. Authenticated users who can create, modify, or import workflows naming these hidden node types can execute JavaScript in the n8n main process.

n8n before 1.123.85, 2.43.5, and 2.44.1 contains a credential guard bypass vulnerability that allows editors of shared workflows to use restricted credentials by loading sub-workflows from URLs or local files. Attackers can configure the Execute Sub-workflow node with source url or localFile to serve content that resolves project credentials and returns their decrypted values.

n8n before 1.123.85, 2.43.5, and 2.44.1 contains a credential guard bypass vulnerability that allows editors of shared workflows to use restricted credentials by loading sub-workflows from URLs or local files. Attackers can configure the Execute Sub-workflow node with source url or localFile to serve content that resolves project credentials and returns their decrypted values.

n8n before 1.123.85, 2.43.5, and 2.44.1 contains a regular expression denial of service vulnerability that allows authenticated members to block the event loop via crafted glob patterns. Attackers who can create and run workflows can submit a wildcard-heavy File(s) Selector pattern causing exponential backtracking, making the UI, API, webhooks, and health checks unresponsive until restart.

n8n before 1.123.85, 2.43.5, and 2.44.1 contains a regular expression denial of service vulnerability that allows authenticated members to block the event loop via crafted glob patterns. Attackers who can create and run workflows can submit a wildcard-heavy File(s) Selector pattern causing exponential backtracking, making the UI, API, webhooks, and health checks unresponsive until restart.