Impact n8n contains a critical Remote Code Execution (RCE) vulnerability in its workflow expression evaluation system. Under certain conditions, expressions supplied by authenticated users during workflow configuration may be evaluated in an execution context that is not sufficiently isolated from the underlying runtime.

An authenticated attacker could abuse this behavior to execute arbitrary code with the privileges of the n8n process. Successful exploitation may lead to full compromise of the affected instance, including unauthorized access to sensitive data, modification of workflows, and execution of system-level operations.

Patches This issue has been fixed in n8n v1.122.0.

Users are strongly advised to upgrade to version 1.122.0 or later, which introduces additional safeguards to restrict expression evaluation.

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 eliminate the risk and should only be used as short-term measures.

Impact An authenticated user with permission to create or modify workflows could exploit a prototype pollution vulnerability in the GSuiteAdmin node. By supplying a crafted parameter as part of node configuration, an attacker could write attacker-controlled values onto Object.prototype. An attacker could use this prototype pollution to achieve remote code execution on the n8n instance.

Patches The issue has been fixed in n8n versions 2.14.1, 2.13.3, and 1.123.27. 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 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.

n8n before 2.32.1 (and before 2.31.5) is vulnerable to account takeover via the Token Exchange Embed Login feature. When a validly-signed incoming token was matched to a local account by its email claim, the service did not verify that the email claim was verified, nor that the trusted key's permitted role ceiling covered that account. As a result, anyone able to obtain a token accepted by a configured trusted key (for example, a trusted issuer emitting unverified email addresses) could authenticate as any existing user and gain full account control. This issue only affects instances where the embed login feature is enabled and at least one trusted key source is configured.

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.

Impact A remote code execution vulnerability exists in the Git Node component available in both Cloud and Self-Hosted versions of n8n. When a malicious actor clones a remote repository containing a pre-commit hook, the subsequent use of the Commit operation in the Git Node can inadvertently trigger the hook’s execution.

This allows attackers to execute arbitrary code within the n8n environment, potentially compromising the system and any connected credentials or workflows.

All users with workflows that utilize the Git Node to clone untrusted repositories are affected.

Patches The vulnerability was addressed in v1.113.0 (n8n-io/n8n#19559), which introduces a new environment variable: N8NGITNODEDISABLEBAREREPOS. For self-hosted deployments, it is strongly recommended to set this variable to true to mitigate the risk of executing malicious Git hooks.

Workarounds To reduce risk prior to upgrading:

- Avoid cloning or interacting with untrusted repositories using the Git Node. - Disable or restrict the use of the Git Node in workflows where repository content cannot be fully trusted.

Impact When LDAP authentication is enabled, n8n automatically linked an LDAP identity to an existing local account if the LDAP email attribute matched the local account's email. An authenticated LDAP user who could control their own LDAP email attribute could set it to match another user's email — including an administrator's — and upon login gain full access to that account. The account linkage persisted even if the LDAP email was later reverted, resulting in a permanent account takeover.

- LDAP authentication must be configured and active (non-default).

Patches The issue has been fixed in n8n versions 2.4.0 and 1.121.0. 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 LDAP authentication until the instance can be upgraded. - Restrict LDAP directory permissions so that users cannot modify their own email attributes. - Audit existing LDAP-linked accounts for unexpected account associations.

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 exploit a SQL injection vulnerability in the Data Table Get node. On default SQLite DB, single statements can be manipulated and the attack surface is practically limited. On PostgreSQL deployments, multi-statement execution is possible, enabling data modification and deletion.

Patches The issue has been fixed in n8n versions 1.123.26, 2.13.3, and 2.14.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 Data Table node by adding n8n-nodes-base.dataTable to the NODESEXCLUDE environment variable. - Review existing workflows for Data Table Get nodes where orderByColumn is set to an expression that incorporates external or user-supplied input.

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

n8n before 1.123.67, 2.x before 2.31.5, and 2.32.x before 2.32.1 contain a remote code execution vulnerability in the Git node. Authenticated users with rights to create and execute workflows can stage a crafted local repository that causes git to run hooks under default git security settings, executing arbitrary commands as the n8n process user. Both self-hosted and cloud instances are affected.

n8n before 2.31.5 and before 2.32.1 contain a sandbox escape vulnerability in expression evaluation. An authenticated user with permission to create or modify workflows can craft expressions using arrow-function bodies to bypass the expression sandbox, triggering system command execution on the host running n8n. The issue is fixed in versions 2.31.5 and 2.32.1.

n8n before 2.33.4 and 2.34.x before 2.34.1 contain a remote code execution vulnerability in the @n8n/workflow-sdk node-schema loader used for MCP node-schema loading. The loader derives a node's schema module path directly from the attacker-supplied node type string without validating path-traversal sequences. An authenticated user with global:member privileges can reference malicious files via path traversal, causing code execution in the n8n main process.

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.

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.

n8n before 1.123.69, 2.x before 2.33.4, and 2.34.x before 2.34.1 contain an expression injection vulnerability in resource-locator field link preview rendering. The editor spliced the field's stored value directly into the node type's URL template without checking for expression syntax. An authenticated member can store a malicious value so that when another user opens the affected node in the editor, the injected expression is evaluated as JavaScript in the victim's authenticated session (cross-user script execution).

n8n before 1.123.69, 2.33.4, and 2.34.1 contains a stored cross-site scripting vulnerability in the Form node's completion page. The completion page applied its sandboxing Content-Security-Policy only when respondWith was not set to 'redirect', but responseText was always rendered as raw HTML. An authenticated member could set respondWith to 'redirect' via an expression while keeping responseText populated, causing the completion page to serve unsanitized HTML and script from the n8n origin. Any visitor who submitted the resulting public form would have that script execute same-origin with their session.

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.

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.

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.

n8n versions before 1.123.67, 2.31.5, and 2.32.1 contain an arbitrary file write vulnerability in the Edit Image node, which passes its output format parameter to the underlying image library without validation. An authenticated user able to run workflows can supply a crafted format value to write arbitrary files outside the node's working directory on the n8n instance.

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 versions before 1.123.73, 2.35.4, and 2.36.2 contain a remote code execution vulnerability in the Git node. The node reset a fixed list of command-bearing configuration keys before each operation, but that list did not cover the content-filter and merge-driver key families. A repository with local configuration setting one of those keys together with a matching attribute pattern causes git to execute the configured command during an ordinary Add, Commit, Checkout, or Pull operation. The command runs as the n8n process user.

Impact When an n8n instance is configured with more than one trusted token-exchange issuer, external identities are resolved to local accounts using only the JWT sub claim, ignoring the issuer (iss). As a result, two different issuers that emit the same subject value map to the same local account.

An attacker who can obtain a valid token from one trusted issuer with a sub matching a victim registered under a different issuer can authenticate as that victim and access their account.

This issue only affects instances where the token exchange feature is enabled and more than one trusted external issuer is configured.

Patches The issue has been fixed in n8n version 2.28.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: - If multiple trusted issuers are not required, reduce the token exchange configuration to a single trusted issuer. - Disable the token exchange feature entirely if it is not in active use.

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

Impact An authenticated user without permission to list external secrets could reference a secret by the external name in a credential and retrieve its plaintext value when saving the credential. This bypassed the externalSecret:list permission check and allowed access to secrets stored in connected vaults without admin or owner privileges.

- This issue requires the instance to have an external secrets vault configured. - The attacker must know or be able to guess the name of a target secret.

Patches The issue has been fixed in n8n versions 1.123.23 and 2.6.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: - Restrict n8n access to fully trusted users only. - Disable external secrets integration until the patch can be applied.

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

n8n before 1.123.67, 2.31.5, and 2.32.1 validates credential-access only for a node's top-level credentials and not for credentials referenced inside an Execute Sub-workflow node's inline workflow JSON. A member with Editor access to a shared workflow (when workflow sharing is enabled) who knows a target credential's ID can reference that credential in the inline JSON; it passes save-time and runtime validation and resolves in the parent workflow's project context, allowing the attacker to use or exfiltrate credentials they are not permitted to access.

n8n versions before 1.123.69, 2.33.4, and 2.34.1 contain a JavaScript task runner VM sandbox escape. The runner's prototype-freezing routine covers globalThis functions but not internal module constructors such as EventEmitter, allowing an authenticated user with Code node access to exploit prototype pollution to execute arbitrary commands within the runner container. Because the polluted prototype is a process-wide object, the corruption persists across other tenants' Code node executions on the same shared runner. On v1.x instances without task runners enabled, Code node JavaScript runs directly in the main n8n process, where the impact could be higher.

n8n versions before 2.36.2 contain an expression sandbox bypass vulnerability where free identifiers in spread, computed-key, switch-case, or class-extension positions resolve against process globals. Authenticated users with workflow-edit permission can mutate host objects through expression evaluation, with changes persisting process-wide until restart.

Impact The AI Agents feature did not enforce the "Allowed HTTP Request Domains" restriction configured on credentials. As a result, a member-level user who had been granted use-only access to a shared credential could cause its secret to be sent to an external server they control, by pointing an MCP tool at an arbitrary URL and running the agent.

This issue only affects instances where the AI Agents module is enabled via N8NENABLEDMODULES=agents and at least one credential with domain restrictions has been shared with a member-level user.

Patches The issue has been fixed in n8n version 2.28.1 and 2.27.4. 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 AI Agents module by removing agents from the N8NENABLEDMODULES environment variable. - 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.

n8n versions before 2.32.1 fail to enforce the Allowed HTTP Request Domains allowlist in multiple AI and LLM nodes when user-supplied base or endpoint URLs are configured. Low-privileged workflow editors with use-only access to shared credentials can redirect requests to attacker-controlled hosts and exfiltrate credential secrets for reuse against underlying services.

n8n before 1.123.67, 2.31.5, and 2.32.1 contains a prototype pollution vulnerability in the Edit Fields (Set) node. The node assigns output fields via a dot-notation path setter without restricting the field name, allowing an authenticated user to name a field after an inherited built-in method path and corrupt a shared global in the main Node.js process. Because that global is used on the request-authentication path, the instance then fails every authenticated request, causing an instance-wide denial of service for all users until the process is restarted.