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

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.

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