n8n is a workflow automation platform. In n8n versions before 1.123.76, 2.37.7, and 2.38.2, the source control push endpoint derived the set of files to push from the file paths and status supplied in the client request payload instead of from the server-side status computed for the requesting user. An authenticated project-scoped user (e.g., a project admin) could therefore reference files belonging to projects they have no access to and push a deletion of those projects' workflows and credentials, resulting in cross-project data destruction. Exploitation requires the Source Control (Environments) enterprise feature to be licensed, enabled, and connected to a remote repository. The issue is fixed in 1.123.76, 2.37.7, and 2.38.2.

n8n is a workflow automation platform. In versions before 1.123.76, 2.37.7, and 2.38.2, the Git node validated a relative remote URL against the configured repositoryPath but then invoked git with that path as its working directory; git walked up to the enclosing repository's top level and resolved the same relative URL from there. An authenticated user (member) who nested the repository one level below the configured path could therefore make an identical URL string pass the file-access check while git resolved it outside the sandbox. A subsequent fetch or pull read a git repository outside N8NRESTRICTFILEACCESSTO and merged its objects into the user's own repository, where their contents could be read back. The issue is fixed in n8n 1.123.76, 2.37.7, and 2.38.2, which resolve the remote reference from the directory git actually operates in before applying the sandbox check. As a workaround, the Git node can be disabled by adding n8n-nodes-base.git to NODESEXCLUDE.

Impact

The OAuth Dynamic Client Registration endpoints validated field sizes only for redirecturis, leaving clientname and granttypes bounded by presence checks alone. An unauthenticated remote caller could submit arbitrarily large values in either field and have them persisted to the database. Repeated registration therefore grew persistent storage without limit and without any account on the instance. The patch caps clientname at its column length and limits granttypes to the grant types the server actually implements, with the array capped at that count.

Patches

The issue has been fixed in n8n versions 2.37.7 and 2.38.2. 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 network access to the n8n instance so that only trusted clients can reach it. - Place the instance behind a reverse proxy configured to enforce strict request body size limits below the default 16 MiB. - Monitor database size for unexpected growth and audit the oauthclients table for anomalous entries.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

The expression compiler's sanitizer resolved through a dynamically-scoped this, so a class field named sanitize rebound it and reached the Function constructor. On the backend, any expression author could run code in the n8n process; in the editor preview, a member's expression could run as JavaScript in the session of whoever opened the workflow. The patch rejects reserved class-member names.

Patches

The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. 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. - Avoid granting workflow-create or workflow-edit permissions to untrusted users. - Audit existing workflows for unexpected or unfamiliar expressions in node parameters. - Set N8NEXPRESSIONENGINE=vm.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

The /chat WebSocket route resumed a paused execution from a resume token without checking that the node being resumed was a chat node. n8n hands that token to anonymous form submitters, so a party with no account could present it on the chat route and release an execution waiting at an approval gate, the control an author puts in front of an action considered too consequential to automate. The patch restricts resume over the chat route and Chat Hub to chat-capable node types.

Patches

The issue has been fixed in n8n versions 2.37.7 and 2.38.2. 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. - Avoid workflows that combine a Form Trigger with non-chat approval gates (Send-and-Wait, Telegram/Slack/Gmail HITL, or plain Wait nodes) on publicly accessible instances. - Audit recent executions of such workflows for unexpected completion without a corresponding approval callback.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

The Instance AI workflow summary built its result with get-or-create-then-nested-write idioms keyed by node names and connection keys taken from the stored workflow. Those are arbitrary strings: the restricted-name guard n8n shows in the editor is client-side and is bypassed by posting the workflow to the REST API directly. So a reserved key such as proto resolved up the prototype chain instead of creating an own key, and the write landed on Object.prototype in the main n8n process, affecting every later request. The patch builds the summary with null-prototype accumulators and validates the keys it accepts, so reserved names cannot reach the prototype chain.

Patches

The issue has been fixed in n8n versions 2.37.7 and 2.38.2. 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. - Remove or leave unconfigured the N8NINSTANCEAIMODEL environment variables to prevent the Instance AI module from reaching the vulnerable code path. - Restart the n8n process to clear any in-memory prototype pollution if an attack is suspected.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

The Elasticsearch and ElasticSecurity nodes built REST endpoints by interpolating user-provided identifiers straight into the request path. A value containing path separators or dot segments changed which endpoint the request actually reached, so an operation intended for one document could hit another index or a cluster administration endpoint instead, under the stored Elasticsearch credential. The patch encodes each identifier as a single URL path segment and rejects values that normalise away.

Patches

The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. 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 affected nodes by adding n8n-nodes-base.elasticsearch and n8n-nodes-base.elasticSecurity to the NODESEXCLUDE environment variable if they are not required. - Audit existing workflows that use these nodes and ensure that index and document identifier fields do not accept externally-controlled input.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

The GitHub Trigger generated a signing secret when it registered a webhook and verified X-Hub-Signature-256 on each delivery. When GitHub answered the create request with a 422 because a webhook for the URL already existed, the node adopted the remote hook but kept only its id and events, discarding the secret it had generated. Deliveries to that workflow's webhook URL were then accepted from anyone. The patch re-fetches the existing hook by its stored id, re-applies the signing secret, and makes verification fail closed when no secret is stored.

Patches

The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. 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: - Deactivate and reactivate any GitHub Trigger workflows to force a fresh webhook registration with a new secret, provided the remote GitHub hook has been deleted first so that the 422 reuse path is not taken again. - Restrict network access to the n8n webhook endpoint to GitHub's published IP ranges only. - Audit GitHub Trigger workflow static data for entries that contain a webhookId but no webhookSecret, and treat those workflows as unprotected until reactivated successfully.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

The OpenAI Chat Model node checked a custom base URL against the credential's allowed-domains configuration before sending a request, but the model-search dropdown did not. A request setting options.baseURL on that path reached an arbitrary host with the credential attached, so the domain restriction an administrator configured did not hold for every route the node offered. The patch routes every OpenAI call site, including model listing, through one shared allowed-domains check.

Patches

The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. 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. - Audit all domain-restricted openAiApi credentials and revoke use-only shares granted to untrusted users. - Rotate any openAiApi credential secrets that may have been exposed and review downstream OpenAI account activity for unexpected usage.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

Two stages of expression code generation built source text by calling the global JSON.stringify at generation time: the compiler when printing synthetic string literals, and the isolate bridge when interpolating a timezone value into its per-evaluation wrapper. An expression that replaced that global therefore changed the code that was subsequently generated and executed, turning literal data into executable source. The patch renders both code-generation stages through a reference captured at module load, so a later change to global state cannot alter the generated source.

This vulnerability only affects instances running the legacy expression engine. The vm expression engine, which is the default on the patched releases, is not affected.

Patches

The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. 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: - Set the environment variable N8NEXPRESSIONENGINE=vm to switch to the vm expression engine, which is not affected by this vulnerability. - Restrict n8n instance access to fully trusted users only. - Ensure the n8n process runs under a dedicated low-privilege OS user account to limit the impact of any command execution.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

The public OIDC login and callback endpoints ran the full flow whether or not OIDC was the instance's active, enabled authentication method, so turning OIDC off in Settings did not stop it issuing sessions. An administrator who disabled the provider still had a working login route. The patch requires OIDC to be the enabled, active authentication method before either endpoint starts the flow or issues a session.

The issue affects n8n Enterprise instances where OIDC was configured at least once and subsequently disabled.

Patches

The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. 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 or revoke the corresponding application or client at the IdP level to prevent the OIDC flow from completing. - Restrict network-level 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 endpoints /rest/roles/:slug/assignments and /rest/roles/:slug/assignments/:projectId/members checked only that the caller could manage the role type, not that they could see the project named in the request. A user holding role-management permission could therefore name any project on the instance and read back its members' names and email addresses. The patch adds a project-access check to both routes, hiding projects the caller cannot see and returning not-found for a project it cannot list.

Patches

The issue has been fixed in n8n versions 2.38.2 and 2.37.7. 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. - Audit and revoke any custom global roles that carry the role:manageProject scope, limiting that scope to fully trusted users only.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

A log streaming event destination may reference a generic HTTP credential, and the destination resolved and decrypted whichever credential it named without checking that the caller had access to it. A user holding a custom global role scoped to Log Streaming operations could therefore name a credential belonging to another project and have its decrypted secret sent to an endpoint they controlled. The patch applies the standard credential access check when a destination resolves its credential.

Patches

The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. 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. - Audit and revoke any custom global roles that carry Log Streaming scopes (eventBusDestination:create, eventBusDestination:test, etc.), limiting those scopes to fully trusted users only. - Review existing Log Streaming event destinations for unexpected webhook URLs and remove any that are not recognized, then rotate any credentials that may have been referenced.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

The endpoint /rest/active-workflows returned every active workflow ID on the instance to any member, regardless of sharing, and workflow activation, deactivation and publication push events were broadcast to every connected client, carrying workflow IDs, version IDs and activation-error detail across users. The patch scopes both the listing and the push events through the sharing service, so a user only sees workflows they can access.

Patches

The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. 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. - Avoid provisioning global:member accounts for untrusted users until the instance is patched.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

The Git node validated the repository that a fetch or pull targeted, but setUpstream wrote a branch.<name>.remote value into the repository's own configuration without validating it. A subsequent fetch or pull resolved the remote from that configuration rather than from the checked parameter, so an authenticated user with workflow-edit permission could point it at any local repository the n8n process could read and receive its contents. The patch validates the branch remote configuration on the same terms as the repository parameter.

Patches

The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. 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. - Ensure the n8n process runs under a dedicated low-privilege OS user account to limit the scope of any filesystem access.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

A workflow's "This workflow can be called by" setting was enforced by the Execute Workflow node but was not consulted when the same workflow was attached to an Agent as a tool. A user who could build an Agent could therefore call a workflow that its owner had restricted, and read back what it returned. The patch applies the sub-workflow caller policy on the Agent tool path.

Patches

The issue has been fixed in n8n versions 2.37.7 and 2.38.2. 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. - Audit workflows attached as Agent tools and review their caller policy settings. - Remove sensitive workflows from Agent tool configurations until the instance is patched.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

Instance AI credential setup accepted a credential test/verification URL without checking it matched the workflow node's origin. Exfiltration required the user to actively inject an attacker-controlled URL into the setup flow. The patch derives the credential destination from the node's own URL and confines authenticated requests, redirects and probes to that origin.

Patches

The issue has been fixed in n8n versions 2.38.2 and 2.37.7. 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 Instance AI module by removing instance-ai from the N8NENABLEDMODULES environment variable if it is not required. - Restrict n8n instance access to fully trusted users only. - Rotate any third-party API credentials that were set up using the Instance AI credential-setup flow on affected versions.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Impact

The OAuth token endpoint bound an authorization code's first access token to the consented resource, but not its refresh token. Refreshing only checked that the requested resource was registered, not that it matched the original grant. An OAuth client approved for one workflow could refresh with a different workflow's URL and get a valid, unapproved token for it. The patch binds refresh tokens to the granted resource and rejects mismatches.

Exploitation requires the attacker to register an OAuth client, convince an authenticated user to approve that client for one known protected resource, and know the URL of a second protected resource that the consenting user is permitted to execute.

Patches

The issue has been fixed in n8n versions 2.38.1 and 2.37.7. 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. - Deactivate MCP Trigger, form, and webhook workflows that are protected by the n8n OAuth server if they are not required. - Audit connected OAuth clients and revoke any that are not recognized or no longer needed. - Require re-authorization for all existing OAuth clients after upgrading, as previously issued refresh tokens did not store the original resource binding.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

n8n versions before 2.36.2 contain a missing per-project authorization vulnerability in the Insights API routes that allows authenticated users with insights scopes to access workflow names and execution statistics across projects. Attackers can supply arbitrary projectId parameters to retrieve sensitive project and workflow information from projects they have no membership in.

n8n versions before 2.34.1 contain a server-side request forgery vulnerability in the legacy request helper function exposed to Code and Function nodes. The validation logic checks the uri property for SSRF safety while the underlying HTTP client uses the url property when both are present, allowing attackers to bypass validation by supplying a safe uri alongside a malicious url to access internal addresses.

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 pass message content in the Gmail (v1) and Brevo nodes to the mail composer without verifying it is a string. An authenticated user able to run a workflow can supply an expression that resolves to an object carrying a path or href property, causing the composer to read a local file accessible to the n8n process or fetch an internal URL (SSRF) and attach the result to the outgoing message.

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 contain a query injection vulnerability in the Elasticsearch Document Get All and Google Cloud Firestore Document Query operations, which build their JSON query by interpolating expression values directly into the query string before parsing. A value containing quote and brace characters can close the intended field and introduce new query operators, turning an intended single-document lookup into a full-collection read.

n8n versions before 1.123.73, 2.35.4, and 2.36.2 contain a remote code execution vulnerability in the Git node. The node reset a fixed list of command-bearing configuration keys before each operation, but that list did not cover the content-filter and merge-driver key families. A repository with local configuration setting one of those keys together with a matching attribute pattern causes git to execute the configured command during an ordinary Add, Commit, Checkout, or Pull operation. The command runs as the n8n process user.

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 versions before 2.36.2 contain an expression sandbox bypass vulnerability where free identifiers in spread, computed-key, switch-case, or class-extension positions resolve against process globals. Authenticated users with workflow-edit permission can mutate host objects through expression evaluation, with changes persisting process-wide until restart.

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