n8n vulnerabilities

The setWebhookResolver in the application (likely n8n) lacks validation of user-supplied URLs. An authenticated user can make the server send repeated requests to internal endpoints, including link-local metadata addresses. The response is not returned via the API, making the attack blind.

Vulnerability in n8n before versions 1.123.67, 2.31.5, and 2.32.1 allows credential authorization bypass in the HTTP Request node. An authenticated member with edit access to a shared workflow can reference another user's credential while specifying the credential type via an expression. Because the pre-execution permission check compares the unresolved expression instead of the resolved credential type, the ownership check is skipped and the credential is loaded at execution time, allowing the member to use or exfiltrate a credential they were not granted.

Vulnerability in n8n before versions 2.31.5 and 2.32.1 allows 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 could authenticate as any existing user and gain full account control.

n8n before 1.123.67, 2.31.5, and 2.32.1 contains a prototype pollution vulnerability in the VM expression engine. An authenticated user able to create or edit a workflow expression can abuse the engine's array-element access to obtain a reference to a host built-in and pollute its prototype in the main n8n process (a sandbox escape), leading to a denial of service. Both self-hosted and cloud instances running the VM expression engine are affected.

Vulnerability in n8n before versions 1.123.67, 2.31.5, and 2.32.1 allows remote code execution 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's JavaScript task runner shared a single module cache across all users' Code-node executions. In affected versions (before 1.123.67, 2.31.5, and 2.32.1), a user able to run a Code node could poison a cached module and thereby alter other users' Code-node executions on the same runner, affecting their confidentiality, integrity, or availability. This is a cross-user isolation break within a single n8n instance and does not constitute a sandbox escape or remote code execution. Only multi-user instances running the JS task runner with built-in or external modules enabled are affected.

Vulnerability in n8n before versions 1.123.67, 2.31.5, and 2.32.1 allows arbitrary file write 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 is an open source workflow automation platform. Prior to versions 1.123.32, 2.17.4, and 2.18.1, an authenticated user with permission to create or modify workflows could achieve global prototype pollution via the XML Node leading to RCE when combined with other nodes exploiting the prototype pollution. This issue has been patched in versions 1.123.32, 2.17.4, and 2.18.1.

In n8n before 2.29.8 and 2.30.x before 2.30.1, the @n8n/computer-use package does not enforce shell sandbox restrictions on Linux and Windows (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 versions before 2.20.0 contain a credential exfiltration vulnerability in the POST /rest/dynamic-node-parameters/options endpoint that allows authenticated users to bypass Allowed HTTP Request Domains restrictions. Attackers with credential access can cause the n8n server to issue HTTP requests with credentials to unauthorized hosts.

n8n is a workflow automation platform that prior to versions 1.123.32, 2.17.4, and 2.18.1 was vulnerable to an unauthenticated attacker registering a malicious OAuth client. After authorization by the victim, a malicious script could be executed in the victim's browser session.

In n8n, an open source workflow automation platform, additional expression evaluation vulnerabilities have been found. An authenticated user with permission to create or modify workflows can abuse crafted expressions to trigger unintended system command execution on the host.

In n8n versions 0.121.2 and below, an authenticated attacker may be able to execute malicious code using the n8n service. This could result in full compromise and can impact both self-hosted and n8n Cloud instances. This issue is fixed in version 1.121.3. Administrators can reduce exposure by disabling the Git node and limiting access for untrusted users, but upgrading to the latest version is recommended.

In n8n versions starting with 1.65.0 and below 1.121.0, an attacker can access files on the underlying server through execution of certain form-based workflows. A vulnerable workflow could grant access to an unauthenticated remote attacker, resulting in exposure of sensitive information stored on the system and may enable further compromise depending on deployment configuration and workflow usage. This issue is fixed in version 1.121.0.

n8n from version 1.0.0 to before 2.0.0 has a sandbox bypass vulnerability in the Python Code Node that uses Pyodide. An authenticated user with permission to create or modify workflows can exploit this to execute arbitrary commands on the host system running n8n, using the same privileges as the n8n process.

n8n before 2.34.1 and 2.33.x before 2.33.4 contains an SSRF protection bypass in the SearXNG Agent tool. The tool sent requests to the user-supplied API URL using a raw HTTP client that did not route through n8n's centralized SSRF protection. On instances with N8N_SSRF_PROTECTION_ENABLED=true, an authenticated user with permission to create SearXNG credentials and configure a personal agent could set the API URL to an internal host, causing the n8n server to connect to that host and return the response content through the Agent chat output.

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 is a workflow automation platform. In versions prior to 1.123.69, 2.33.4, and 2.34.1, the JavaScript Code node's VM sandbox did not freeze the sandbox's Function.prototype, allowing an authenticated user with the ability to create and execute workflows to pollute it from within a Code node execution and recover a reference to the host's globalThis, resulting in a sandbox escape. The full exploit chain additionally depends on specific modules being available as allowlisted imports in the deployment's configuration. The issue is fixed in versions 1.123.69, 2.33.4, and 2.34.1.

n8n before 1.123.69, 2.x before 2.33.4, and 2.34.x before 2.34.1 contains a regular expression denial of service (ReDoS) vulnerability in the Filter and Switch nodes, which compile user-supplied regex patterns with new RegExp() and execute them synchronously on the worker thread without complexity validation or execution timeout. A crafted regex pattern can block the worker for an extended period per data item processed, delaying other workflow executions on the same worker.

n8n before 1.123.69, 2.x before 2.33.4, and 2.x before 2.34.1 contain an allowed-domains bypass in the GraphQL node. When the node's Authentication parameter is set to expression mode, every authentication-gated credential selector is treated as active; if two credentials of different types are attached, the node enforces the allowed-domains policy of only the first credential while still attaching material from both. An authenticated user with workflow-authoring rights can thereby send a domain-restricted credential to an attacker-controlled endpoint, exfiltrating it with the leaked credential's permissions.

n8n before 1.123.69, 2.33.4, and 2.34.1 contains an arbitrary file read and write vulnerability in the Snowflake node, which passes free-form Execute Query input 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.

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.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 1.123.69, 2.33.4, and 2.34.1 contain an information disclosure vulnerability in the GraphQL node. When a GraphQL request fails at the connection level, the node re-throws the underlying HTTP client error unchanged instead of wrapping it in n8n's standard error type. That error contains the live request's headers, including a decrypted credential secret, which the execution engine persists verbatim. Any authenticated user able to read the resulting execution can retrieve the decrypted credential secret from the stored run data.

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 versions before 1.123.69 contain a server-side request forgery vulnerability in the Edit Image node's Draw Text operation that allows authenticated users to inject MVG primitives. Attackers can craft malicious text values to issue blind outbound HTTP requests to arbitrary addresses or access local files.

n8n versions before 2.34.1 contain a credential validation bypass in the MCP create_workflow_from_code tool when authentication type is set to an expression. Attackers with a valid MCP Bearer API key and knowledge of a target credential ID can persist unauthorized cross-project credential references on workflows in different projects.

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.

n8n before 1.123.69, 2.33.4, and 2.34.1 contains a PostgREST filter injection vulnerability in the Supabase node's Row Get Many, Delete, and Update operations, which built filter queries by concatenating an expression-bindable value without escaping. An attacker could inject a condition that widened the filter to match every row, turning an intended single-row operation into full-table disclosure, deletion, or modification.

n8n before 1.123.69, 2.33.4, and 2.34.1 contains a NoSQL injection vulnerability in the MongoDB node's Find, Delete, and Aggregate operations, which parse the Query parameter as JSON after expression resolution without sanitizing MongoDB operators. An attacker who can influence the resolved query (e.g., via externally-controlled data) can inject operators such as $ne or $where, turning an intended single-document lookup into full-collection disclosure, full-collection deletion, or other operations on the database server.

A vulnerability in n8n before 1.123.69, 2.33.4, and 2.34.1 is an SSRF protection bypass in the OAuth2 credential authorization-code-to-access-token exchange. The token exchange uses a separate HTTP client without SSRF guard, allowing a user with credential-creation permissions to set the access-token URL to an internal address and complete the OAuth2 flow, causing n8n to send a token-exchange POST to that target and reflect the response back to the attacker.

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.

The scanFeedsResolver in the application (likely n8n) lacks URL validation, allowing an authenticated user to direct the server to arbitrary internal endpoints. The response is parsed as an RSS/Atom feed or HTML, limiting disclosure to feed metadata and RSS/Atom links, but allows distinguishing reachable ports from unreachable ones.

In n8n, an open source workflow automation platform, prior to versions 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.

n8n before 1.123.67, 2.31.5, and 2.32.1 contains a SQL injection vulnerability in the PostgresTrigger node, which interpolates user-supplied identifier parameters (channel, function, and trigger names) into SQL statements without proper escaping. An authenticated user can inject arbitrary SQL executed against the connected PostgreSQL database with the configured credential's privileges, allowing full read and write access.

n8n before 2.31.5 and 2.32.x before 2.32.1 contain a path-confinement bypass in the @n8n/computer-use file-search (search_files) tool. A crafted search pattern can bypass the base-directory confinement check and expand to locations outside the configured directory, causing the tool to return the names and contents of arbitrary local files readable by the daemon's OS user. Any deployment where an actor can influence the tool's search input is affected.

Vulnerability in n8n before version 2.32.1 fails 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.

Vulnerability in n8n before version 1.123.67 contains 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 versions before 2.32.1 contain a server-side request forgery protection bypass vulnerability in the MCP Client node that allows authenticated users to bypass SSRF protections. Attackers can craft workflows that send requests to internal or blocked hosts without routing through SSRF protection, exposing internal services and reading responses back through the workflow.

Vulnerability in n8n before versions 1.123.67, 2.31.5, and 2.32.1 contains 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.

Vulnerability in n8n before versions 2.31.5 and 2.32.1 allows a sandbox escape 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.

Vulnerability in n8n before versions 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 before 1.123.67, 2.31.5, and 2.32.1 contains a SQL injection vulnerability in the Snowflake node's Execute Query operation, which interpolates expression values directly into the SQL string. When a workflow author embeds untrusted, externally-controlled expression data directly in a raw SQL query, that data is not parameterized, allowing SQL injection. The fix adds an optional 'Query Parameters' field to bind values via positional placeholders.

Vulnerability in n8n before versions 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.

n8n versions before 1.123.64, 2.29.8, and 2.30.1 have 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. Since JWT headers are Base64-encoded, the private key could be recovered by anyone logging or inspecting the JWT.

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 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 before versions 1.123.64, 2.29.8, and 2.30.1 fails to enforce the "Allowed HTTP Request Domains" restriction on HTTP-based credentials 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 controlled server and exfiltrate restricted credentials. Affects instances where a credential has "Allowed HTTP Request Domains" configured and is usable by non-owners.

In n8n before versions 2.30.1 and 2.29.8, all Public API key scopes are assigned to JWTs issued through the Token Exchange module regardless of the user's role. A low-privileged user with a valid external JWT can obtain an access token allowing administrator-only operations, including role escalation, user creation, and deletion, and, if unverified Community Package installation is enabled, remote code execution.

n8n before versions 2.29.8 and 2.30.1 (since 2.27.0) does not verify that the authenticated user has access to the workflow referenced as the OAuth resource. A member-level user can register an OAuth client, self-approve consent for another user's workflow, and obtain a valid token. The workflow runs in the owner's context with the owner's credentials.