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 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…
Recommended action: Upgrade to 2.38.1 or 2.37.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.38.2 or 2.37.7 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 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…
Recommended action: Upgrade to 2.38.2, 2.37.7 or 1.123.76 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 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…
Recommended action: Upgrade to 2.38.2 or 2.37.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.),…
Recommended action: Upgrade to 2.38.2, 2.37.7 or 1.123.76 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 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…
Recommended action: Upgrade to 2.38.2, 2.37.7 or 1.123.76 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 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…
Recommended action: Upgrade to 2.38.2, 2.37.7 or 1.123.76 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 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…
Recommended action: Upgrade to 2.38.2, 2.37.7 or 1.123.76 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 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…
Recommended action: Upgrade to 2.38.2 or 2.37.7 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 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.
Recommended action: Upgrade to 2.38.2, 2.37.7 or 1.123.76 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.38.2, 2.37.7 or 1.123.76 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 /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.…
Recommended action: Upgrade to 2.38.2 or 2.37.7 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 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…
Recommended action: Upgrade to 2.38.2, 2.37.7 or 1.123.76 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 Git node's clone operation matched the destination path against the default N8NBLOCKFILEPATTERNS expression, which was written so that a crafted path caused catastrophic backtracking. Evaluation runs synchronously in the main n8n process, so an authenticated user could freeze the instance for everyone with a single workflow execution and no unusual configuration. The patch rewrites the pattern so that matching is linear in the length of the path. 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. - Set N8NBLOCKFILEPATTERNS to a backtracking-safe equivalent pattern to replace the vulnerable…
Recommended action: Upgrade to 2.38.2, 2.37.7 or 1.123.76 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 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…
Recommended action: Upgrade to 2.38.2 or 2.37.7 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 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…
Recommended action: Upgrade to 2.38.2, 2.37.7 or 1.123.76 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.38.2 or 2.37.7 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 Snowflake node's Execute Query operation interpolated expression values directly into the SQL string, making queries built with untrusted data susceptible to SQL injection. Exploitation requires that a workflow author has already embedded untrusted expression data directly in a raw SQL query. 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. The fix introduces an optional "Query Parameters" field that allows values to be bound via positional placeholders rather than interpolated into the query string. 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. - Audit existing workflows that use the Snowflake executeQuery operation and ensure no expression resolving to externally-controlled data is embedded…
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 Postgres Trigger node interpolated user-supplied identifier parameters (channel, function, and trigger names) into SQL statements without proper escaping, so an authenticated user could inject arbitrary SQL executed against the connected PostgreSQL database with the configured credential's privileges. Successful exploitation allows full read and write access to the connected PostgreSQL database. Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5 and 2.32.1. Users should upgrade to 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 PostgresTrigger node by adding n8n-nodes-base.postgresTrigger to the NODESEXCLUDE environment variable. - Ensure PostgreSQL credentials used with n8n are configured with the minimum required privileges and do not use SUPERUSER roles.…
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 JavaScript task runner shared one module cache across all users' Code-node executions, so a user able to run a Code node could poison a cached module and 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. It does not constitute a sandbox escape or remote code execution. All multi-user n8n instances running the JS task runner with built-in or external modules enabled 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 built-in and external module access in Code nodes by unsetting NODEFUNCTIONALLOWBUILTIN and…
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 Custom HTTP headers configured in credentials for certain LLM sub-nodes (including OpenAI, Anthropic, and Lemonade) are masked in the n8n UI but are written in plaintext into execution data during workflow runs. Any authenticated user with access to the execution data for an affected workflow can read the header names and values, which typically contain API keys or other secrets. Because execution data can be persisted to the database and exported, leaked values may remain accessible beyond the lifetime of a single execution. This issue only affects instances where workflows use LLM sub-nodes with custom headers defined in their credentials. 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 access to execution data to fully trusted…
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 DELETE /${restEndpoint}/test-webhook/:id route is registered before the 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. 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 network access to the n8n instance to fully trusted users only. - Place the n8n instance behind a reverse proxy or firewall that requires authentication before reaching the REST API. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Recommended action: Upgrade to 2.27.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The GraphQL node did not enforce the "Allowed HTTP Request Domains" restriction on HTTP-based credentials (such as Header Auth, Basic Auth, Query Auth, and OAuth), unlike the HTTP Request node. An authenticated user able to create or edit workflows could therefore 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. 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 workflow creation and editing permissions to fully trusted users only. - Restrict credential sharing to fully trusted users only. - Audit credentials with domain restrictions for unexpected sharing…
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 OAuth 2.1 consent and token-issuance flow introduced in n8n 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 n8n OAuth2-protected MCP Server Trigger workflow, and obtain a valid token for it. The workflow runs in the owner's project context with the owner's stored credentials. The attacker sets the tool inputs and reads the outputs, which may include data from the owner's connected integrations, breaking user and project isolation. The resulting executions appear under the owner's account and are not visible to the attacker. This issue only affects instances running n8n 2.27.0 or later where at least one active workflow uses an MCP Server Trigger node configured with n8n OAuth2 authentication. 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…
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 The shell tool in the @n8n/computer-use package applied its sandbox restrictions only on macOS. On Linux and Windows, shell commands executed by the tool ran 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. It does not affect standard n8n installations. 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. The fix adds sandbox enforcement on Linux via bubblewrap and disables the shell tool entirely when a working sandbox cannot be established. An explicit opt-out flag (--dangerously-disable-shell-sandbox) is available for deployments that require unsandboxed shell access and accept the associated risk. Workarounds If upgrading is not immediately possible,…
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.