Impact Three EE endpoints used by the Dynamic Credentials feature accepted any authenticated n8n session without performing per-resource ownership or scope checks on the target workflow or credential. An authenticated user with no project membership or credential sharing relationship could enumerate credential identifiers, names, and types referenced by any private workflow in the instance, initiate an OAuth authorization flow against another user's credential to overwrite its stored tokens with tokens bound to an account they control, or revoke another user's stored credential tokens entirely.
Workflows relying on a hijacked credential would subsequently execute under the attacker's OAuth identity, enabling data exfiltration to attacker-controlled external services and persistent takeover of integrations. Token revocation would break affected workflows.
This issue only affects Enterprise instances where the Dynamic Credentials feature is enabled.
Patches The issue has been fixed in n8n versions 1.123.55, 2.25.7, and 2.26.2. 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 instance access to fully trusted users only. - If the Dynamic Credentials feature is not actively required, disable it by unsetting N8NENVFEATDYNAMICCREDENTIALS.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact When @n8n/mcp-browser is run in HTTP transport mode, the MCP endpoint accepts session initialization and tool invocation requests without any authentication. Any network-reachable client, or any website visited by the user, can establish an MCP session and invoke browser-control tools.
Where the n8n AI Browser Bridge extension is installed and a browser connection is active, an unauthenticated caller can access browser-control capabilities including navigation, JavaScript evaluation, and cookie and storage access against the user's real browser profile.
This issue only affects instances where @n8n/mcp-browser is run with the HTTP transport (--transport http). The default transport is stdio, which is not affected.
Patches The issue has been fixed in n8n versions 2.25.7, and 2.26.2. 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: - Avoid running @n8n/mcp-browser with the HTTP transport; use the default stdio transport instead. - If HTTP transport is required, restrict network access to the listening port to trusted clients only using host-based firewall rules.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact A member-level user with editor access to a shared workflow could reference credentials they do not own via specific public API endpoints. Credential ownership checks were only enforced partially leading to cross-user credential access.
This issue affects instances where workflow sharing is enabled and at least one workflow has been shared with a member-level user as an Editor.
Patches The issue has been fixed in n8n versions 1.123.55, 2.25.7, and 2.26.2. 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 workflow sharing to fully trusted users only. - Audit shared workflows for unexpected credential references or recent modifications.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Credits: Momen Elkhouli
Impact An authenticated user with permission to create or modify workflows and access to a SecurityScorecard credential with limited allowed domains could configure the SecurityScorecard node's report download operation to target an attacker-controlled URL. The node attached the SecurityScorecard API token to the outbound request, causing the credential to be sent to the attacker-controlled host bypassing credential configured limitations and exfiltrating.
Patches The issue has been fixed in n8n versions 1.123.55, 2.25.7, and 2.26.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 SecurityScorecard node by adding n8n-nodes-base.securityScorecard 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 authenticated user with workflow edit access could configure a Respond to Webhook node to serve binary content with an attacker-controlled Content-Type. The binary response path bypassed the central Content-Security-Policy sandbox header, allowing a public webhook to execute JavaScript in the n8n origin when visited by an authenticated user, with access to that user's session.
Patches The issue has been fixed in n8n versions 1.123.55, 2.25.7, and 2.26.2. 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 Respond to Webhook node by adding n8n-nodes-base.respondToWebhook 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 authenticated user with workflow edit access could inject arbitrary JavaScript into the Chat Trigger's generated page by setting a malicious webhookId. When a logged-in user visited the chat URL, the injected code executed in the n8n origin with that user's session privileges.
Patches The issue has been fixed in n8n versions 1.123.55, 2.25.7, and 2.26.2. 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.
Impact An authenticated user with permission to create or modify workflows could supply a crafted parameters to the TimescaleDB and/or legacy Postgres v1 node's allowing arbitrary SQL to be injected and executed against the connected database within the privileges of the configured database account.
Patches The issue has been fixed in n8n versions 2.25.7, and 2.26.2. 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 Postgres and TimescaleDB node by adding n8n-nodes-base.postgres, n8n-nodes-base.timescaleDb to the NODESEXCLUDE environment variable.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact The MicrosoftAgent365Trigger and StripeTrigger node did not validate that inbound requests. As a result, an unauthenticated attacker who knows the webhook URL could submit a forged payload and cause the workflow to execute with attacker-controlled data.
Patches The issue has been fixed in n8n versions 2.25.7, and 2.26.2. 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: - Deactivate any workflows using the Microsoft Agent 365 Trigger node or Stripe Trigger node until the instance can be upgraded. - Restrict network access to the n8n webhook endpoint to trusted sources only.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact A prototype pollution vulnerability allowed a crafted public webhook payload to inject attacker-controlled fields into workflow data during internal object copying. These fields could be surfaced and consumed as normal values by downstream built-in nodes.
Where a workflow combines a public webhook with action nodes that consume the resulting fields, an attacker could cause the workflow to act as a confused deputy — targeting unintended records or issuing outbound requests using the workflow owner's configured credentials.
Patches The issue has been fixed in n8n versions 2.25.7, and 2.26.2. 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: - Avoid exposing public (unauthenticated) webhook workflows that pass incoming data through transform nodes into action nodes with sensitive credentials or database operations. - 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 pollute the sandbox used by the Merge node's SQL Query mode. Because the sandbox context was cached and reused across all workflow executions on the instance, prototype mutations introduced by one user's workflow persist into subsequent Merge SQL executions belonging to other users or projects. This allowed a low-privileged attacker to intercept workflow data processed by other users on the same instance.
This issue only affects multi-user n8n instances where more than one user has permission to create and execute workflows containing the Merge node in SQL Query mode.
Patches The issue has been fixed in n8n versions 2.25.7, and 2.26.2. 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.
n8n before 2.25.7 and 2.26.x before 2.26.2 contains an abstract syntax tree (AST) security validator bypass in the Python Code node. An authenticated user with permission to create or modify workflows containing a Python Code node can bypass the validator and access the task executor module namespace. The issue only affects self-hosted instances where the Python Task Runner is enabled; where N8NBLOCKRUNNERENVACCESS is configured to allow it, this can disclose environment variables accessible to the task runner process.
n8n before 1.123.55, 2.25.7, and 2.26.2 contains an authorization bypass in the POST /workflows/{workflowId}/test-runs/new endpoint, which authorizes access using the workflow:read scope instead of workflow:execute. An authenticated user with read-only access to a workflow can trigger a real evaluation test run, causing the workflow to execute via the internal workflow runner and resulting in unintended outbound API calls, data mutations, or other side effects in connected downstream systems. The issue primarily affects instances using the Evaluations feature where RBAC project roles grant workflow:read without workflow:execute.
n8n before 1.123.55, 2.25.7, and 2.26.2 contains an authorization vulnerability in three mutating evaluation test-run endpoints that authorize state-changing actions using the workflow:read scope instead of the action-appropriate workflow:execute scope. On instances using Advanced Permissions (Enterprise/Cloud) with projects and viewer roles, an authenticated user with the project:viewer role can start new evaluation test runs, cancel in-flight runs, and delete run records for workflows they only have read access to.
n8n before 2.25.7 and 2.26.x before 2.26.2 contains an authorization bypass in the Public API execution retry endpoint, which authorizes access using the workflow:read scope instead of workflow:execute. An authenticated user with read-only access to a shared workflow can use the Public API to retry executions of that workflow, bypassing the intended permission boundary between read and execute access. This affects instances where workflows are shared with other users or across projects.