n8n before 1.123.69 (and 2.x before 2.33.4 / 2.34.1) contains a code execution vulnerability in the Git node. The Git node executed certain repository-local git configuration values without neutralizing them, so any subsequent Git node operation against a repository containing a malicious value would execute it as the n8n process user. This is not reachable through the Git node's own configuration controls and requires a separate file-write vulnerability elsewhere to plant the malicious value.

n8n is a workflow automation platform. In versions prior to 1.123.69, 2.33.4, and 2.34.1, the JavaScript Code node's VM sandbox did not freeze the sandbox's Function.prototype, allowing an authenticated user with the ability to create and execute workflows to pollute it from within a Code node execution and recover a reference to the host's globalThis, resulting in a sandbox escape. The full exploit chain additionally depends on specific modules being available as allowlisted imports in the deployment's configuration. The issue is fixed in versions 1.123.69, 2.33.4, and 2.34.1.

n8n before 1.123.69, 2.x before 2.33.4, and 2.34.x before 2.34.1 contains a regular expression denial of service (ReDoS) vulnerability in the Filter and Switch nodes, which compile user-supplied regex patterns with new RegExp() and execute them synchronously on the worker thread without complexity validation or execution timeout. A crafted regex pattern can block the worker for an extended period per data item processed, delaying other workflow executions on the same worker.

n8n before 1.123.69, 2.x before 2.33.4, and 2.x before 2.34.1 contain an allowed-domains bypass in the GraphQL node. When the node's Authentication parameter is set to expression mode, every authentication-gated credential selector is treated as active; if two credentials of different types are attached, the node enforces the allowed-domains policy of only the first credential while still attaching material from both. An authenticated user with workflow-authoring rights can thereby send a domain-restricted credential to an attacker-controlled endpoint, exfiltrating it with the leaked credential's permissions.

n8n before 1.123.69, 2.x before 2.33.4, and 2.34.x before 2.34.1 contain an arbitrary file read and write vulnerability in the Snowflake node, which passes free-form Execute Query input, including client-side commands, directly to the Snowflake SDK without applying n8n's file-access restrictions. An authenticated user with usable Snowflake credentials can upload a local file from the n8n host or overwrite an existing file with a staged one.

n8n before 1.123.67, 2.x before 2.31.5, and 2.32.x before 2.32.1 contain a type confusion vulnerability in the Send Email node, which does not enforce that its message fields are strings. A crafted non-string value supplied from a workflow expression into the text or HTML body field can be interpreted by the underlying mail library (Nodemailer) as a file path or URL, allowing arbitrary local file disclosure and server-side request forgery (SSRF). Exploitation requires a pre-existing active workflow with an unauthenticated webhook, valid SMTP credentials configured on the node, and untrusted input mapped directly into the body field; this is not a default configuration.

n8n before 1.123.67, 2.31.5, and 2.32.1 contains a SQL injection vulnerability in the Snowflake node's Execute Query operation, which interpolates expression values directly into the SQL string. When a workflow author embeds untrusted, externally-controlled expression data directly in a raw SQL query, that data is not parameterized, allowing SQL injection. The fix adds an optional 'Query Parameters' field to bind values via positional placeholders.

Impact Additional exploits in the expression evaluation of n8n have been identified and patched following CVE-2025-68613. An authenticated user with permission to create or modify workflows could abuse crafted expressions in workflow parameters to trigger unintended system command execution on the host running n8n.

Patches The issues have been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of these versions or later to remediate all known vulnerabilities.

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. - Deploy n8n in a hardened environment with restricted operating system privileges and network access to reduce the impact of potential exploitation.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Resources - Best practices for securing n8n - Initial vulnerability advisory: CVE-2025-68613

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

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

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 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 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 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 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 An authenticated user can repeatedly upload files to the data-table upload endpoint, bypassing the per-request quota check, which does not account for files already written to the shared temporary directory. This causes temporary files to accumulate on disk until the periodic cleanup runs, potentially exhausting available disk space on the host.

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. - Set uploadMaxFileSize to a low value to limit individual upload size. - Monitor and alert on disk usage in the n8n temporary upload directory.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact The legacy MySQL v1 node's executeQuery operation substitutes evaluated {{ ... }} expression values directly into the raw SQL string without parameterization. If a workflow uses this operation with expression-sourced values in the query and is connected to an externally-reachable trigger (such as a Webhook node), attacker-controlled input reaching those expressions results in SQL injection.

Successful exploitation allows arbitrary SQL execution with the configured MySQL credentials' privileges, enabling unauthorized disclosure, modification, or deletion of data in the downstream database. MySQL v2 node is not affected.

This issue can affect only instances running workflows that use the MySQL v1 node with executeQuery operations.

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 possible, administrators should consider the following temporary mitigations: - Disable the MySQL node by adding n8n-nodes-base.mySql to the NODESEXCLUDE environment variable, or audit and restrict access to workflows using the MySQL v1 node with the executeQuery operation. - Ensure that webhook endpoints used in workflows containing MySQL v1 executeQuery nodes with expression interpolation require authentication. - Migrate affected workflows to use the MySQL v2 node, which uses parameterized queries.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact Due to a mismatch between the static validation check and the runtime expression engine, an authenticated user with credential create or update permissions, but without the externalSecret:list scope, could embed external secret references into credentials in forms the validation did not detect. These references would resolve at workflow execution time, exposing secret values the user was not authorized to access.

This issue only affects instances where an external secrets provider is configured and Advanced Permissions are in use.

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 possible, administrators should consider the following temporary mitigations: - Restrict credential creation and update permissions to fully trusted users only. - Audit existing credentials for unexpected external secret references.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact An authenticated user with the default workflow:create permission could pollute Object.prototype through a crafted workflow saved, updated, or imported via the workflow API. This can be leveraged to bypass authentication, allowing unauthenticated requests to be treated as a privileged user and exposing endpoints such as the user and project listings. As a result, every account's personal data (email, role, MFA status) and all projects on the instance may be disclosed to unauthenticated callers. The pollution can also corrupt global state, making parts of the instance unresponsive until restarted.

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 possible, administrators should consider the following temporary mitigations: - Restrict workflow creation and editing permissions to fully trusted users only. - Restrict network access to the n8n instance to trusted users only.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

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 possible, administrators should consider the following temporary mitigations: - Restrict workflow sharing to fully trusted users only. - Avoid sharing credentials with use-only access to untrusted users on workflows that use HTTP Request nodes with pagination enabled.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

n8n contains an authentication bypass in the Chat Trigger node when configured with n8n User Auth (a non-default configuration). In affected releases — before 1.123.22, the 2.0.0 through 2.9.2 line, and 2.10.0 — the authentication check on the Chat Trigger webhook endpoint can be circumvented, allowing access without valid credentials. Fixed in 1.123.22, 2.9.3, and 2.10.1.

n8n before 1.123.24, 2.10.4, and 2.12.0 (across its 1.x and 2.x branches) contains cross-site scripting and open redirect vulnerabilities in the Form Node due to unsanitized HTML description fields and overly permissive iframe sandbox policies. Authenticated users with workflow creation permissions can inject malicious scripts or redirect parameters to perform stored XSS attacks or phishing redirects against end users.

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 versions 1.123.18 and 2.6.2 fails to verify HMAC-SHA256 signatures on Zendesk webhooks in the ZendeskTrigger node. Attackers who know the webhook URL can send unsigned POST requests to trigger workflows with arbitrary malicious data.

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 contains a stored cross-site scripting vulnerability in the Chat Trigger node's Custom CSS field due to a misconfiguration of the sanitize-html library. Affected releases are those before 1.123.27, the 2.0.0 through 2.13.2 line, and 2.14.0 (fixed in 1.123.27, 2.13.3, and 2.14.1). An authenticated user with permission to create or modify workflows can inject JavaScript that bypasses sanitization, resulting in stored XSS against any user who visits the public chat page.

Impact The OAuth1 and OAuth2 credential reconnect endpoints authorized access using credential:read rather than credential:update. An authenticated user with read-only access to a shared credential could initiate an OAuth reconnect flow and overwrite the stored token material for that credential with tokens bound to an external account they control. Workflows relying on the affected credential would subsequently execute under the attacker's OAuth identity, enabling data exfiltration to attacker-controlled external services and persistent takeover of shared integrations.

This issue affects instances where credentials are shared with other users or across projects.

Patches The issue has been fixed in n8n versions 1.123.43, 2.20.7, and 2.21.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 credential sharing to fully trusted users only. - Audit shared credentials for unexpected OAuth token changes and revoke any tokens that may have been replaced.

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 advisories. CVSS 3.1 vector strings are provided for backwards compatibility.

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N

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.