n8n before 1.123.73, 2.35.4, and 2.36.2 contains a credential exposure vulnerability in the Strapi, SeaTable, and Mailcheck nodes. These nodes send their decrypted credentials to the authentication endpoint via the raw legacy HTTP helper outside any error handling, causing the plaintext secret to be persisted in execution error data. Any authenticated user can read the plaintext secret from their own execution through the REST API, bypassing the blank-value redaction enforced by the credentials API.
n8n versions before 1.123.73, 2.35.4, and 2.36.2 contain an expression sandbox escape in the $fromAI handler. $fromAI resolved a caller-supplied placeholder name without requiring it to be an own property and admitted reserved keys; against a primitive input value it returned a live host-prototype reference. An attacker with workflow-build privilege can walk the prototype chain to the Function constructor and compile/execute arbitrary code in the main n8n process, leading to remote code execution.
n8n before 2.35.4 and 2.36.x before 2.36.2 does not validate credential references in the inline workflow JSON of nodes that execute an inline sub-workflow (e.g., the Workflow Tool node). A shared-workflow editor, or any user creating/updating a workflow via the REST API, Public API, or MCP, can persist a node referencing a credential they do not own. When the workflow is later executed under an identity that holds the credential, the inline sub-workflow resolves the secret and can send it to an attacker-controlled endpoint, resulting in credential exfiltration.
n8n before 1.123.69, 2.33.4, and 2.34.1 contains an SSRF protection bypass in the OAuth2 credential authorization-code-to-access-token exchange. While OAuth2 discovery and dynamic-client-registration requests use n8n's SSRF-protected HTTP client, the token exchange uses a separate client with no SSRF guard. A user with credential-creation permissions can set the access-token URL to an internal address and complete the OAuth2 flow, causing n8n to send a fixed-shape token-exchange POST to that target and reflect its response body back to the attacker (limited to what the target returns to this specific request).
n8n before 2.34.1 and 2.33.4 contains an authorization bypass in the custom project role deletion (reassignment) path. When deleting a custom project role with a reassignment target, the code validated only that the target role existed and was project-scoped, performing no project-level authorization check. A user holding only the narrow role:manageProject global scope could delete any custom project role in use on the instance and reassign its holders (including themselves) to the built-in project:admin role, gaining full administrative control of projects they had no legitimate access to.
n8n versions before 1.123.67 contain a path traversal vulnerability in the Git node's fetch, pull, and push-tags operations that allows authenticated users to bypass repository-path containment checks. Attackers with workflow create/execute rights can point allowlisted remote configurations at local paths outside the sandbox to pull arbitrary git repositories and read their files and history.
n8n is an open source workflow automation platform. Prior to 1.123.64, 2.29.8, and 2.30.1, the Git node clone operation allows an authenticated workflow user to swap a validated directory for a symlink before cloning, planting a crafted repository in the community node directory that loads as a custom JavaScript node after restart and executes arbitrary code on the server. This issue is fixed in versions 1.123.64, 2.29.8, and 2.30.1.
Impact In n8n's AI Agents feature, a user with the read-only Project Viewer role could escalate their privileges by chatting with an agent that has node tools enabled. The agent's node-execution tool was authorized only by the agent:execute scope and ran nodes using the project's credentials, without verifying that the requesting user was permitted to execute nodes or to access those credentials.
As a result, a Project Viewer could execute arbitrary tool nodes on the server and use credential secrets they were not authorized to read, gaining execution capabilities their role is intended to deny. On instances where a command- or file-capable tool node (such as Execute Command or SSH) is enabled, this could be extended to arbitrary command execution on the n8n host.
Users of the AI Agents feature who share team projects with lower-privileged members are affected.
Patches The issue has been fixed in n8n versions 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 the AI Agents module by removing agents from the N8NENABLEDMODULES environment variable. - Restrict project membership to fully trusted users only, and avoid granting Project Viewer access to untrusted users on projects containing agents with node tools enabled. - Disable command-execution nodes (e.g. Execute Command, SSH) if they have been re-enabled, to limit the potential impact.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
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 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 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 before 2.25.7 and 2.26.x before 2.26.2 contains an abstract syntax tree (AST) security validator bypass in the Python Code node. An authenticated user with permission to create or modify workflows containing a Python Code node can bypass the validator and access the task executor module namespace. The issue only affects self-hosted instances where the Python Task Runner is enabled; where N8NBLOCKRUNNERENVACCESS is configured to allow it, this can disclose environment variables accessible to the task runner process.
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.
n8n before 2.8.0 contains an authentication bypass vulnerability allowing authenticated SSO users to disable SSO enforcement through the API. Attackers can create local password credentials to authenticate directly, bypassing organizational SSO policies and identity-provider-enforced multi-factor authentication.
n8n: authenticated SSRF in GET /rest/workflows/from-url; affected: <=2.19.x unconditionally, and 2.20.0+ when N8NSSRFPROTECTIONENABLED is unset (default false); verified on 2.27.4 (stable, source review) and 2.28.2 (pre-release, live test); CWE-918; CVE: none; fix was independent prior vendor work, not credited here.
GET /rest/workflows/from-url accepts a user-controlled url parameter and makes a server-side HTTP request to it. Any authenticated user with project-scoped workflow:create permission can use this to reach loopback, link-local, and RFC1918 addresses. If the target returns JSON shaped like an n8n workflow ({"nodes":..., "connections":...}), the body is reflected to the caller.
The relevant code path is packages/cli/src/workflows/workflows.controller.ts, where fetchWorkflowFromUrl() now uses:
private async fetchWorkflowFromUrl(url: string) { const client = this.outboundHttp.requests({ ssrf: this.ssrfConfig.enabled ? this.ssrfProtectionService : 'disabled', }); ... }
The gate is this.ssrfConfig.enabled. In packages/@n8n/config/src/configs/ssrf-protection.config.ts (verified on tag n8n@2.28.2):
@Env('N8NSSRFPROTECTIONENABLED') enabled: boolean = false;
So 2.20.0 added SSRF protection for this path, but behind an opt-in flag that defaults to false. Default installs therefore remain exploitable. Current stable 2.27.4 is affected by source review. The current pre-release 2.28.2 is affected by live test. 2.28.2 is not a stable release.
When N8NSSRFPROTECTIONENABLED=true, the request is routed through SsrfProtectionService, which checks resolved IPs before the request, at connect time via custom lookup, and across redirects. With the flag unset, the request is made with ssrf: 'disabled'.
Minimal PoC (executed 2026-06-26 local time against n8nio/n8n:2.28.2; listener timestamps below are UTC):
docker run -d -p 5678:5678 \ -e N8NSECURECOOKIE=false \ n8nio/n8n:2.28.2
curl -s -G -b cookies.txt \ 'http://localhost:5678/rest/workflows/from-url' \ --data-urlencode "projectId=$PROJECTID" \ --data-urlencode 'url=http://172.17.0.1:8888/'
Default install result:
{"data":{"nodes":[],"connections":{},"secret":"SSRFCONFIRMED2282"}} --> HTTP 200
Listener log on the internal host:
2026-06-27T04:20:15Z VICTIM-HIT path=/ UA=n8n from=172.17.0.2
A loopback target such as http://127.0.0.1:5678/rest/settings also causes the server-side request to be issued; the response is HTTP 400 only because that body is not workflow-shaped.
With N8NSSRFPROTECTIONENABLED=true, the same request returns:
{"code":0,"message":"The request was blocked because it resolves to a restricted IP address"} --> HTTP 400
and no new listener hit is recorded.
Vendor handling / timeline:
2026-04-27 n8n opened PR #29178 under ticket CAT-2890 2026-04-29 I reported the same issue independently 2026-04-29 PR #29178 merged 2026-05-05 n8n 2.20.0 released with the protection gated by flag 2026-05-20 vendor declined the report 2026-06-26 live PoC re-run against 2.28.2 (local date)
PR #29178 predates my report. I do not claim credit for that fix. The point of this post is narrower: the shipped protection is off by default, so the default configuration remains exploitable on current releases. No CVE or GHSA has been issued.
Mitigation:
set N8NSSRFPROTECTIONENABLED=true
This causes the import endpoint to use the SSRF checks. Network egress filtering is also advisable.
References: - PR #29178: https://github.com/n8n-io/n8n/pull/29178 - Public write-up: https://github.com/akshatgit/public-disclosure/blob/main/advisories/2026-06-26-n8n-ssrf-workflows-from-url.md
Reporter: Akshat Sinha
Impact When workflows process uploaded files and transfer them to remote servers via the SSH node without validating their metadata the vulnerability can lead to files being written to unintended locations on those remote systems potentially leading to remote code execution on those systems.
As a prerequisites an unauthenticated attacker needs knowledge of such workflows existing and the endpoints for file uploads need to be unauthenticated.
Patches The issue has been fixed in n8n version 2.4.0 and 1.123.12. 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 or restrict access to workflows that accept file uploads via webhooks and transfer them via SSH. - Enable webhook authentication on all endpoints that handle file uploads. - Review usage of SSH credentials and consider rotating SSH credentials if in doubt. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Resources - n8n Documentation — Blocking nodes — how to globally disable specific nodes
---
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:N/UI:N/S:C/C:H/I:H/A:H
Impact n8n workflows can store and serve binary files, which are accessible to authenticated users. However, there was no restriction on the MIME type of uploaded files, and the MIME type could be controlled via a GET parameter. This allowed the server to respond with any MIME type, potentially enabling malicious content to be interpreted and executed by the browser.
An authenticated attacker with member-level permissions could exploit this by uploading a crafted HTML file containing malicious JavaScript. When another user visits the binary data endpoint with the MIME type set to text/html, the script executes in the context of the user’s session. This script could, for example, send a request to change the user’s email address in their account settings, effectively enabling account takeover.
Patches
- n8n@1.90.0
Credit We would like to thank @Mahmoud0x00 for reporting this issue.
The n8n package 0.218.0 for Node.js allows Directory Traversal.
The n8n package 0.218.0 for Node.js allows Escalation of Privileges.
The n8n package 0.218.0 for Node.js allows Information Disclosure.