| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| n8n versions before 1.123.64, 2.29.8, and 2.30.1 contain a privilege escalation vulnerability in Enterprise SSO instance-role provisioning. The provisioning path maps an IdP-asserted role claim to an n8n global role but does not prevent assignment of the global:owner role (unlike the token-exchange identity path, which rejects it). An SSO-authenticated user whose instance-role claim resolves to global:owner is provisioned as instance owner, gaining full administrative control over workflows, credentials, users, and instance configuration. Exploitation requires that Enterprise SSO is configured, instance-role provisioning is enabled via N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE (disabled by default), and the attacker controls the instance-role claim value issued by the IdP. |
| n8n before 2.29.8 and 2.30.x before 2.30.1 (affected from 2.27.0, when the OAuth 2.1 consent and token-issuance flow was introduced) does not verify that the authenticated user has access to the workflow referenced as the OAuth resource. On instances with at least one active MCP Server Trigger workflow configured with n8n OAuth2 authentication, a member-level user can register an OAuth client, self-approve consent for another user's workflow, and obtain a valid token. The workflow then runs in the owner's project context with the owner's stored credentials, and the attacker can set tool inputs and read outputs (potentially including data from the owner's connected integrations), breaking user and project isolation. |
| n8n versions before 1.123.64 fail to properly mask custom HTTP header credentials in LLM sub-node execution data, writing plaintext API keys and secrets to workflow execution records. Authenticated users with access to execution data can read exposed header values and credentials that persist in the database and can be exported. |
| n8n before 2.30.1 and 2.29.8 assigns all Public API key scopes to JWTs issued through the Token Exchange module regardless of the acting user's role. On instances where the Token Exchange feature and Public API are enabled, a low-privileged user who can obtain a valid external JWT trusted by a configured issuer can use the resulting access token to invoke administrator-only Public API operations such as role escalation, user creation, and user deletion (role escalation requires an Advanced Permissions license), and, when unverified Community Package installation is enabled, achieve remote code execution. |
| n8n versions before 2.30.1 contain a privilege escalation vulnerability in the AI Agents feature where the node-execution tool lacks proper authorization checks. A Project Viewer user can escalate privileges by chatting with an agent that has node tools enabled, executing arbitrary nodes and accessing credential secrets without proper authorization verification. |
| n8n versions before 1.123.64 contain a server-side request forgery vulnerability in the dynamic-node-parameters endpoints that lack authorization scopes. Authenticated attackers can supply absolute URLs in routing configuration to override baseURL restrictions and make the n8n server issue HTTP requests to arbitrary internal targets when SSRF protection is disabled. |
| n8n versions before 1.123.64, 2.29.8, and 2.30.1 contain a credential exposure vulnerability: when configured with a Google Service Account key, the full PEM private key was mistakenly placed in the JWT header's kid field (intended only for a key identifier). Because JWT headers are Base64-encoded rather than encrypted, the private 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. |
| n8n before 1.123.64, 2.x before 2.29.8, and before 2.30.1 contains a DOM-based cross-site scripting vulnerability in the HTML preview, which renders execution output into an iframe srcdoc without the sandbox attribute. A sanitizer bypass allows injected script to execute same-origin as the editor. When a victim opens the preview, the script can call authenticated APIs using the victim's session. An account with global:member privileges can exploit the issue. |
| n8n contains a sanitizer bypass vulnerability in the legacy expression evaluator's computed-member handler. An authenticated user with workflow create or modify permissions can craft a malicious expression to bypass the sanitizer and achieve host-level code execution as the n8n process. The legacy expression engine is the default in affected versions. Fixed in n8n 1.123.64, 2.29.8, and 2.30.1. |
| n8n before 1.123.64, 2.29.8, and 2.30.1 fails to enforce the "Allowed HTTP Request Domains" restriction on HTTP-based credentials (Header Auth, Basic Auth, Query Auth, OAuth) in the GraphQL node, unlike the HTTP Request node. An authenticated user able to create or edit workflows can 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. |
| n8n before 2.29.8 and 2.30.x before 2.30.1 does not enforce shell sandbox restrictions on Linux and Windows in the @n8n/computer-use package (sandboxing was applied only on macOS). Shell commands executed by the tool run 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; standard n8n installations are not affected. |
| n8n before 2.28.0 (and before 2.27.4 on the 2.27.x branch) registers the DELETE /${restEndpoint}/test-webhook/:id endpoint before authentication middleware is applied, allowing any unauthenticated network caller who knows a workflow ID to cancel that workflow's active test webhook registration. The impact is limited to disrupting in-progress test sessions; production webhooks, persistent workflow state, and stored data are not affected. |
| n8n before 1.123.64, 2.29.8, and 2.30.1 contains a stored DOM cross-site scripting vulnerability in the Resource Locator component, which passes the workflow-persisted cachedResultUrl parameter to window.open() without scheme validation. An attacker with workflow creation/editing privileges can craft a workflow with a malicious (e.g., javascript:) scheme in cachedResultUrl; when a victim opens the crafted workflow and interacts with external links, the payload executes in the victim's browser. |
| n8n before 1.123.64, 2.29.8, and 2.30.1 contains a TOCTOU race condition in the Git node's clone operation that allows authenticated users to bypass path restrictions by swapping a directory for a symlink after the path is validated but before the clone runs. This lets an attacker plant a crafted repository in the community node directory, which n8n loads as a custom node on the next restart, executing arbitrary JavaScript on the server. Both self-hosted and cloud instances are affected. |
| 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 versions 1.123.61, 2.27.4, and 2.28.1 contains a permission bypass vulnerability in external secrets handling caused by 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 can embed external secret references into credentials in forms the static validation does not detect; these references resolve at workflow execution time, exposing secret values the user is not authorized to access. This issue only affects instances where an external secrets provider is configured and Advanced Permissions are in use. |
| n8n before 2.19.3 contains a file path restriction bypass in the legacy ExecuteWorkflow node's localFile source option, which reads workflow files from disk without the file-access checks enforced by other file-reading nodes. Although hidden from the UI since v1.2, it remains reachable via the REST API. An authenticated user with permission to create or modify workflows can supply an arbitrary file path to bypass the N8N_RESTRICT_FILE_ACCESS_TO restriction and determine whether arbitrary files exist on the host; where the targeted path contains a valid workflow JSON file, that file can additionally be loaded and executed. |
| n8n before 2.28.1 contains an information disclosure vulnerability where external secrets are incorrectly resolved in workflow node expressions outside credentials scope. Authenticated project editors can read plaintext external secret values by referencing them in node expressions without requiring explicit secrets access permissions. |
| n8n before version 2.10.0 contains an input validation vulnerability in the Guardrail node that allows attackers to bypass default guardrail instructions. End users can craft malicious inputs to circumvent guardrail protections and compromise workflow integrity. |
| n8n is an open source workflow automation platform. Prior to 2.27.4 and from 2.28.0 prior to 2.28.1, n8n instances configured with more than one trusted token-exchange issuer resolved external identities to local accounts using only the JWT sub claim and ignored the iss claim, allowing an attacker with a valid token from one trusted issuer and a sub matching a victim under another issuer to authenticate as that victim. This issue is fixed in versions 2.27.4 and 2.28.1. |
