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 member with use-only editor access to a shared workflow could read credential-populated headers exposed via the $request object inside an HTTP Request node's pagination expression. When an HTTP Header Auth credential is applied to a paginated request, the secret is present in $request.headers when pagination expressions are evaluated. A user-controlled expression could read that secret, copy it into item data, and exfiltrate it through a later HTTP Request node, bypassing credential domain restrictions, since the secret leaves via item data rather than the credential's own request mechanism. This issue only affects instances with N8NEXPRESSIONENGINE=vm set, where paginated HTTP Request workflows using shared credentials are accessible to non-owner users. Patches The issue has been fixed in n8n versions 1.123.61, 2.27.4, and 2.28.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately…
Recommended action: Upgrade to 2.28.1, 2.27.4 or 1.123.61 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 n8n was configured with a Google Service Account key, the full PEM private key was mistakenly placed in the JWT header's kid field (which should only have held a key identifier). Since JWT headers were Base64-encoded rather than encrypted, the key could be recovered by anything that logged or inspected the JWT. An attacker who obtained the key could impersonate the service account and access or modify any Google Cloud resource it was authorized to use. Only instances using Google Service Account credentials are affected. Patches The issue has been fixed in n8n versions 1.123.64, 2.29.8, and 2.30.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: - Avoid using Google Service Account credentials until the instance is patched. - Rotate any Google Service Account keys that may have been used with an affected n8n…
Recommended action: Upgrade to 2.30.1, 2.29.8 or 1.123.64 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 Resource Locator passes the workflow-persisted cachedResultUrl to window.open() without scheme validation. When a victim opens the crafted workflow and interact with external links, the JavaScript payload runs in the victim's browser. Patches The issue has been fixed in n8n versions 1.123.64, 2.29.8, and 2.30.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 workflow creation and editing permissions to fully trusted users only. - Audit existing workflows for unexpected cachedResultUrl values containing non-HTTP(S) schemes. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.30.1, 2.29.8 or 1.123.64 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 HTML preview renders execution output into an iframe srcdoc without sandbox, so a sanitizer bypass lets injected script run same-origin as the editor. When a victim opens the preview, it can call authenticated APIs with their session. An account with global:member privileges can exploit it. Patches The issue has been fixed in n8n versions 1.123.64, 2.29.8, and 2.30.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 instance access to fully trusted users only. - Set the N8NCONTENTSECURITYPOLICY environment variable to a policy that blocks inline scripts. - Avoid exposing workflows that render externally-controlled input into the HTML node or binary HTML preview to untrusted users. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.30.1, 2.29.8 or 1.123.64 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 TOCTOU race condition in the Git node's clone operation lets an authenticated user bypass its path restrictions by swapping a directory for a symlink after the path is validated but before the clone runs. This plants a crafted repository in the community node directory, which n8n loads as a custom node on the next restart, and since nodes execute JavaScript, this yields arbitrary code execution on the server. Both self-hosted and cloud instances are affected, where authenticated users can create and run workflows using the Git node. Patches Users should upgrade to the patched version once available 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. - Disable the Git node by adding n8n-nodes-base.git to the NODESEXCLUDE environment variable. - Restrict network egress from the n8n instance to prevent connections to…
Recommended action: Upgrade to 2.30.1, 2.29.8 or 1.123.64 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In n8n's AI Agents feature, a user with the read-only Project Viewer role could escalate their privileges by chatting with an agent that has node tools enabled. The agent's node-execution tool was authorized only by the agent:execute scope and ran nodes using the project's credentials, without verifying that the requesting user was permitted to execute nodes or to access those credentials. As a result, a Project Viewer could execute arbitrary tool nodes on the server and use credential secrets they were not authorized to read, gaining execution capabilities their role is intended to deny. On instances where a command- or file-capable tool node (such as Execute Command or SSH) is enabled, this could be extended to arbitrary command execution on the n8n host. Users of the AI Agents feature who share team projects with lower-privileged members are affected. Patches The issue has been fixed in n8n versions 2.29.8 and 2.30.1. Users should upgrade to one of these versions or later…
Recommended action: Upgrade to 2.30.1 or 2.29.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 Three mutating endpoints in the evaluation test runs controller authorized state-changing actions using workflow:read instead of the action-appropriate workflow:execute scope. An authenticated user with project:viewer role on a project could start new evaluation test runs, cancel in-flight runs, and delete run records for workflows they only had read access to. This issue only affects instances with Advanced Permissions (Enterprise/Cloud) where projects and viewer roles are in use. 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 project membership to fully trusted users only. - Avoid granting viewer access to projects containing sensitive workflows. These workarounds do not fully remediate the risk and should only be used as…
Recommended action: Upgrade to 2.26.2, 2.25.7 or 1.123.55 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 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…
Recommended action: Upgrade to 2.26.1, 2.25.7 or 1.123.55 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 @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…
Recommended action: Upgrade to 2.26.2 or 2.25.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.26.2, 2.25.7 or 1.123.55 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 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. --- n8n has adopted CVSS 4.0 as primary score for all security…
Recommended action: Upgrade to 2.26.2, 2.25.7 or 1.123.55 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 Compression node's Decompress operation expanded attacker-controlled archives into memory without enforcing limits on decompressed output size. An unauthenticated attacker could send a small compressed archive to a public webhook workflow using this node, causing the n8n process to terminate due to memory exhaustion and disrupting all workflows in the same instance. Patches The issue has been fixed in n8n version 2.24.0. Users should upgrade to this version or later to remediate the vulnerability. The fix introduces configurable limits on decompressed output size (N8NCOMPRESSIONNODEMAXDECOMPRESSEDSIZEBYTES) and ZIP entry count (N8NCOMPRESSIONNODEMAXZIPENTRIES). Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Disable the Compression node by adding n8n-nodes-base.compression to the NODESEXCLUDE environment variable. - Restrict public webhook workflows that accept archive file uploads to authenticated…
Recommended action: Upgrade to 2.24.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 Public API endpoint for retrying executions authorized access using workflow:read rather than workflow:execute. An authenticated user with read-only access to a shared workflow could use the Public API to retry executions of that workflow, bypassing the intended permission boundary between read and execute access. This issue affects instances where workflows are shared with other users or across projects. 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: - Restrict workflow sharing to fully trusted users only. - Restrict network access to the n8n Public API 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.26.2 or 2.25.7 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 bypass the AST security validator and access the task executor module namespace. On self-hosted instances where N8NBLOCKRUNNERENVACCESS=false is set, this extended to disclosure of environment variables accessible to the task runner process. This issue only affects instances where the Python Task Runner is enabled and N8NBLOCKRUNNERENVACCESS=true. 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 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…
Recommended action: Upgrade to 2.26.2 or 2.25.7 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 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.
Recommended action: Upgrade to 2.26.2, 2.25.7 or 1.123.55 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 endpoint in the Meta and Microsoft Teams trigger nodes reflects a query parameter into the HTTP response without sanitization or Content-Security-Policy headers, enabling reflected XSS in the n8n origin when a logged-in user visits a crafted URL. Patches The issue has been fixed in n8n version 2.24.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 activation permissions to fully trusted users only. - Disable the affected nodes by adding n8n-nodes-base.facebookTrigger, n8n-nodes-base.whatsAppTrigger, n8n-nodes-base.facebookLeadAdsTrigger, and n8n-nodes-base.microsoftTeamsTrigger 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.24.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 achieve global prototype pollution via the Microsoft SQL node by supplying a crafted value as the table parameter. This pollutes Object.prototype process-wide for the lifetime of the n8n server process, causing application-wide validation failures and rendering the n8n instance completely non-functional until restarted. Patches The issue has been fixed in n8n version 2.24.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 Microsoft SQL node by adding n8n-nodes-base.microsoftSql 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.24.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 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…
Recommended action: Upgrade to 2.26.2 or 2.25.7 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 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…
Recommended action: Upgrade to 2.26.2 or 2.25.7 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 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.
Recommended action: Upgrade to 2.26.2, 2.25.7 or 1.123.55 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 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.
Recommended action: Upgrade to 2.26.2 or 2.25.7 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 /workflows/{workflowId}/test-runs/new endpoint authorized access using workflow:read rather than workflow:execute. An authenticated user with read-only access to a workflow could trigger a real evaluation test run, causing the workflow to execute via the internal workflow runner. This could result in unintended outbound API calls, data mutations, or other side effects in downstream systems connected to the workflow. This issue primarily affects instances where the Evaluations feature is in use and where users may have workflow:read access without workflow:execute access, such as deployments using RBAC project roles. 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 access to fully trusted users only. - Audit…
Recommended action: Upgrade to 2.26.2, 2.25.7 or 1.123.55 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 workflow edit access could supply a malicious filter value in the MongoDB node's Find And Replace operation. The value was not validated before being passed to MongoDB as a query filter, allowing unintended documents to be matched and overwritten with attacker-controlled content. Patches The issue has been fixed in n8n version 2.24.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 MongoDB node by adding n8n-nodes-base.mongoDb 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.24.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 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.
Recommended action: Upgrade to 2.26.2 or 2.25.7 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 supply a local filesystem path as the source repository in the Git node's Clone operation, or as the target repository in the Push operation, bypassing the N8NRESTRICTFILEACCESSTO file sandbox. This allowed the contents of any local git repository accessible to the n8n process to be cloned into an allowed path and read, circumventing the access restrictions that correctly blocked direct file reads to the same paths. 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 Git node by adding n8n-nodes-base.git to the NODESEXCLUDE environment variable. These workarounds do not fully…
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.