Impact The legacy expression evaluator's computed-member sanitizer can be bypassed by an authenticated user with workflow create or modify permissions. Successful exploitation grants the attacker host-level code execution as the n8n process.
The legacy expression engine is the default engine in affected versions.
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. - Switch to the non-legacy expression engine by setting N8NEXPRESSIONENGINE=vm.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
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 attacker-controlled git repositories.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact
JWTs issued through the Token Exchange module were assigned all Public API key scopes, regardless of the acting user's actual role. A low-privileged user who could obtain a valid external JWT trusted by a configured issuer could therefore use the resulting access token to invoke administrator-only Public API operations, such as role escalation, user creation, and user deletion.
The issue only affects instances where the Token Exchange feature and the Public API are enabled (N8NTOKENEXCHANGEENABLED=true, N8NENVFEATTOKENEXCHANGE=true) and the attacker can obtain an external JWT accepted by a configured trusted key. Role escalation additionally requires an Advanced Permissions license; Community Package installation additionally requires N8NCOMMUNITYPACKAGESENABLED=true and N8NUNVERIFIEDPACKAGESENABLED=true.
Patches
The issue has been fixed in n8n version 2.30.1 and 2.29.8. 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 Token Exchange feature by setting N8NTOKENEXCHANGEENABLED=false or N8NENVFEATTOKENEXCHANGE=false. - If Token Exchange cannot be disabled, restrict Public API access at the network level to trusted clients only. - Disable unverified Community Package installation by setting N8NUNVERIFIEDPACKAGESENABLED=false to eliminate the code execution path.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
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.
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.
Impact n8n's Enterprise SSO instance-role provisioning maps a role claim asserted by the configured Identity Provider (IdP) to an n8n global role and applies it during authentication. The provisioning path did not prevent assignment of the global:owner role, unlike the token-exchange identity path, which explicitly rejects it. As a result, an SSO-authenticated user whose instance-role claim resolves to global:owner is provisioned as an instance owner, obtaining full administrative control over all workflows, credentials, users, and instance configuration.
This is a privilege-escalation issue that is exploitable only under specific conditions. It affects instances where Enterprise SSO is configured and instance-role provisioning is enabled via the N8NSSOSCOPESPROVISIONINSTANCEROLE flag, which is disabled by default. Exploitation additionally requires the attacker to control the value of the instance-role claim issued by the IdP. As this claim is typically an administrator-managed attribute, exploitation generally requires control over the IdP or its claim-to-role mapping, or a permissive IdP configuration in which a lower-privileged user can influence the claim value. Deployments that do not use Enterprise SSO, or that have instance-role provisioning disabled, are not 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: - Disable instance-role provisioning by unsetting or setting N8NSSOSCOPESPROVISIONINSTANCEROLE=false. - Audit IdP claim mappings to ensure no user-controllable attribute can supply the instance-role claim value. - Restrict SSO access to fully trusted users only.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
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 to remediate the vulnerability.
Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Disable the AI Agents module by removing agents from the N8NENABLEDMODULES environment variable. - Restrict project membership to fully trusted users only, and avoid granting Project Viewer access to untrusted users on projects containing agents with node tools enabled. - Disable command-execution nodes (e.g. Execute Command, SSH) if they have been re-enabled, to limit the potential impact.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact
Endpoints in /rest/dynamic-node-parameters/ lacked authorization scopes, making it reachable by any authenticated user with no workflow creation or execution required.
By supplying an absolute URL in the routing configuration, a caller could override the node type's declared baseURL, defeating the restriction meant to confine requests to the node's own upstream service. With SSRF protection disabled by default (N8NSSRFPROTECTIONENABLED=false), this let an authenticated user make the n8n server issue HTTP requests to arbitrary internal targets.
Patches The issue has been fixed in n8n versions 1.123.64, 2.29.8, and 2.30.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: - Restrict n8n instance access to fully trusted users only. - Set N8NSSRFPROTECTIONENABLED=true to enable SSRF filtering for private IP ranges and cloud metadata endpoints. - Restrict network egress from the n8n host to limit reachable internal services.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact The shell tool in the @n8n/computer-use package applied its sandbox restrictions only on macOS. On Linux and Windows, shell commands executed by the tool ran without any filesystem or network restrictions, allowing unrestricted access to the host filesystem and network from within the computer-use agent process.
This issue only affects deployments where the @n8n/computer-use package is explicitly installed and running. It does not affect standard n8n installations.
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 to remediate the vulnerability.
The fix adds sandbox enforcement on Linux via bubblewrap and disables the shell tool entirely when a working sandbox cannot be established. An explicit opt-out flag (--dangerously-disable-shell-sandbox) is available for deployments that require unsandboxed shell access and accept the associated risk.
Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Disable or avoid deploying the @n8n/computer-use package on Linux or Windows hosts until the fix is applied. - Restrict access to the n8n instance and the computer-use agent to fully trusted users only.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact Custom HTTP headers configured in credentials for certain LLM sub-nodes (including OpenAI, Anthropic, and Lemonade) are masked in the n8n UI but are written in plaintext into execution data during workflow runs. Any authenticated user with access to the execution data for an affected workflow can read the header names and values, which typically contain API keys or other secrets.
Because execution data can be persisted to the database and exported, leaked values may remain accessible beyond the lifetime of a single execution.
This issue only affects instances where workflows use LLM sub-nodes with custom headers defined in their credentials.
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 access to execution data to fully trusted users only. - Avoid configuring custom headers in LLM node credentials; use alternative authentication mechanisms where possible. - Rotate any API keys or secrets that may have been stored as custom header values in affected credentials.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
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 version. - Review proxy, load balancer, and application logs for JWT headers that may contain exposed key material and treat any such keys as compromised.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact The OAuth 2.1 consent and token-issuance flow introduced in n8n 2.27.0 does not verify that the authenticated user has access to the workflow referenced as the OAuth resource. A member-level user can register an OAuth client, self-approve consent for another user's n8n OAuth2-protected MCP Server Trigger workflow, and obtain a valid token for it.
The workflow runs in the owner's project context with the owner's stored credentials. The attacker sets the tool inputs and reads the outputs, which may include data from the owner's connected integrations, breaking user and project isolation. The resulting executions appear under the owner's account and are not visible to the attacker.
This issue only affects instances running n8n 2.27.0 or later where at least one active workflow uses an MCP Server Trigger node configured with n8n OAuth2 authentication.
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 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. - Audit active workflows using the MCP Server Trigger with n8n OAuth2 authentication and consider switching to a different authentication method or deactivating them until the patch is applied.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Impact The GraphQL node did not enforce the "Allowed HTTP Request Domains" restriction on HTTP-based credentials (such as Header Auth, Basic Auth, Query Auth, and OAuth), unlike the HTTP Request node. An authenticated user able to create or edit workflows could therefore point the node's endpoint at a server they control and exfiltrate restricted credentials.
Only instances where a credential has "Allowed HTTP Request Domains" configured and is usable by non-owner users 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: - Restrict workflow creation and editing permissions to fully trusted users only. - Restrict credential sharing to fully trusted users only. - Audit credentials with domain restrictions for unexpected sharing relationships.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.