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 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.
Recommended action: Upgrade to 2.28.0 or 1.123.58 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 workflows in one project could bypass project/folder authorization boundaries during workflow creation. By supplying a crafted request payload, the user could associate a newly created workflow with a folder belonging to a different project they do not have access to. The workflow itself remains in the attacker's project and is not visible to the target project's members. The target project's folder ownership is not changed, and no data from the target project is exposed. The impact is limited to a logical integrity violation of the target project's folder structure at the database level. This issue affects instances with multi-project and folder support enabled. Patches The issue has been fixed in n8n version 2.28.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: - Restrict…
Recommended action: Upgrade to 2.28.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact External secrets were incorrectly resolved in workflow node expressions, where they are not intended to be available. An authenticated user with project editor access could read the plaintext value of external secrets by referencing them in a node expression, without needing explicit secrets access permissions. This issue only affects instances with the external secrets feature configured. Patches The issue has been fixed in n8n versions 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 project membership to fully trusted users only. - Avoid granting editor access to projects on instances where external secrets are configured. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.28.1 or 2.27.4 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 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…
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 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…
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 The component @n8n/computer-use file-search tool confined searches to a configured base directory. A crafted search pattern could bypass the confinement check and expand to locations outside that directory, causing the tool to return the names and contents of files anywhere the daemon's OS user could read. Any deployment where an actor could influence the tool's search input was affected; the result was disclosure of arbitrary local files outside the intended sandbox. Patches The issue has been fixed in n8n versions 2.31.5 and 2.32.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. - Disable or remove AI agent workflows that use the computer-use package until the instance is patched. - Ensure the n8n process runs under a dedicated low-privilege user account to…
Recommended action: Upgrade to 2.32.1 or 2.31.5 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 able to create or edit a workflow expression could abuse the expression engine's array-element access to obtain a reference to a host built-in and pollute its prototype in the main n8n process, leading to a denial of service. Both self-hosted and cloud instances running the VM expression engine are affected. Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.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. - Disable the VM expression engine if an alternative is available for your deployment. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.32.1, 2.31.5 or 1.123.67 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 Edit Fields (Set) node assigned output fields through a dot-notation path setter without restricting the field name, so an authenticated user could name a field after an inherited built-in method path and corrupt a shared global in the main Node.js process. Because that global was used on the request-authentication path, the instance then failed every authenticated request, causing a instance-wide denial of service for all users until the process was restarted. Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.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. - Disable or restrict workflow creation and execution permissions for untrusted users. - Monitor for unexpected process-wide HTTP 500 errors and restart the process promptly…
Recommended action: Upgrade to 2.32.1, 2.31.5 or 1.123.67 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 n8n Edit Image node passed its output format to the underlying image library without validation, so a crafted value could write bytes to a location outside the node's working directory. An authenticated user able to run workflows could use this to write arbitrary files in the n8n instance. Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.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. - Disable the Edit Image node by adding n8n-nodes-base.editImage 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.32.1, 2.31.5 or 1.123.67 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact n8n's credential-access checks validated only a node's top-level credentials, not credentials referenced inside an Execute Sub-workflow node's inline workflow JSON. A member with editor access to a shared workflow could reference a credential they were not permitted to use inside that inline JSON; it passed both save-time and runtime validation and resolved in the parent workflow's project context, letting the member use or exfiltrate a credential they could not otherwise access. Exploitation requires workflow sharing to be enabled and the attacker to have been explicitly granted Editor access to a shared workflow. The attacker must also know the target credential's ID. Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.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…
Recommended action: Upgrade to 2.32.1, 2.31.5 or 1.123.67 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 member with edit access to a shared workflow could reference another user's credential in an HTTP Request node while specifying the credential type through an expression. Because the pre-execution permission check compared the unresolved expression instead of the real credential type, the ownership check was skipped and the credential was loaded at execution time, letting the member use or exfiltrate a credential they were never granted. Exploitation required knowing the target credential's identifier. Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.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. - Exclude the HTTP Request node by adding n8n-nodes-base.httpRequest to the NODESEXCLUDE environment variable, if the…
Recommended action: Upgrade to 2.32.1, 2.31.5 or 1.123.67 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 abuse crafted expressions using arrow functions to bypass the expression sandbox, triggering unintended system command execution on the host running n8n. Patches The issue has been fixed in n8n versions 2.31.5 and 2.32.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. - Restrict workflow creation and editing permissions to fully 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.32.1 or 2.31.5 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 n8n Send Email node did not enforce that its message fields were strings, so a crafted untrusted non-string value from a workflow expression could be treated by the underlying mail library as a file path or URL. This could allow disclosure of local files on the n8n host. Exploitation requires a pre-existing active workflow with an unauthenticated webhook, valid SMTP credentials configured on the Send Email node, and untrusted input mapped directly into the text or HTML body field. This is not a default n8n configuration. Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.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: - Audit active workflows for Send Email nodes that map untrusted webhook or external data directly into the text or HTML body fields, and remove or restrict those…
Recommended action: Upgrade to 2.32.1, 2.31.5 or 1.123.67 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Authenticated n8n users with rights to create and execute workflows could achieve code execution on the n8n host. Using the Git node, under the default git security settings, by staging a crafted local repository, an attacker could cause git to run hooks, executing arbitrary commands as the n8n process user. Both self-hosted and cloud instances are affected where authenticated users can create and execute workflows using the Git node. Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.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. - Disable the Git node by adding n8n-nodes-base.git to the NODESEXCLUDE environment variable. - Restrict network egress from the n8n instance to limit the impact of arbitrary code execution. These…
Recommended action: Upgrade to 2.32.1, 2.31.5 or 1.123.67 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact On an n8n instance with SSRF protection enabled, the MCP Client node sent requests to a user-supplied endpoint without routing them through that protection and without pinning the resolved address. An authenticated user who could create or edit a workflow could therefore cause the server to connect to internal or otherwise blocked hosts and read the responses back through the workflow, exposing internal services the SSRF protection was meant to protect. Patches The issue has been fixed in n8n versions 2.31.5 and 2.32.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. - Disable the MCP Client node by adding it to the NODESEXCLUDE environment variable. - Restrict network egress from the n8n host to block access to internal and link-local address ranges at the…
Recommended action: Upgrade to 2.32.1 or 2.31.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Authenticated n8n users with workflow create/execute rights could use the Git node's fetch, pull, or push-tags operations to bypass the repository-path containment checks that already protected clone and push. By pointing an allowlisted remote configuration value at a local path outside the intended sandbox, an attacker could pull an arbitrary local git repository into the workspace and subsequently read its files and history. Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.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. - Disable the Git node by adding n8n-nodes-base.git 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.32.1, 2.31.5 or 1.123.67 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 credential "Allowed HTTP Request Domains" allowlist was intended to restrict which hosts a credential's secret could be sent to, protecting shared credentials from users who could use but not view them. Several AI/LLM nodes did not enforce this allowlist when a user-supplied base or endpoint URL was set. A low-privileged workflow editor with use-only access to such a shared credential could point one of these nodes at an attacker-controlled host and cause the credential secret to be transmitted there, then reuse it against the underlying service. Only instances where a credential has "Allowed HTTP Request Domains" configured and is shared with non-owner users are affected. Patches The issue has been fixed in n8n versions 2.31.5 and 2.32.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…
Recommended action: Upgrade to 2.32.1 or 2.31.5 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 an n8n instance, when a validly-signed incoming token was matched to a local account by its email claim, the service did not check that the trusted key's permitted role ceiling covered that account, nor that the email claim was verified. As a result, anyone able to obtain a token accepted by one of the configured trusted keys, for example a trusted issuer that emitted unverified email addresses, could authenticate as any existing user, gaining full account control. This issue only affects instances where the embed login feature is enabled and at least one trusted key source is configured. Patches The issue has been fixed in n8n version 2.32.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: - Disable the embed login feature by setting N8NTOKENEXCHANGEENABLED=false. - If embed login cannot be disabled, restrict network access…
Recommended action: Upgrade to 2.32.1 or 2.31.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
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 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.
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 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…
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 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…
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 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. -…
Recommended action: Upgrade to 2.28.1 or 2.27.4 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 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…
Recommended action: Upgrade to 2.28.1 or 2.27.4 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 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…
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.