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 A vulnerability in the Merge node's SQL Query mode allowed authenticated users with permission to create or modify workflows to write arbitrary files to the n8n server's filesystem potentially leading to remote code execution. Patches The issue has been fixed in n8n version 2.4.0, 1.118.0. 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: - Limit workflow creation and editing permissions to fully trusted users only. - Disable or restrict use of the Merge node if not essential for operations. - Review workflows for suspicious use of the Merge node's SQL Query mode. 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…
Recommended action: Upgrade to 2.4.0 or 1.118.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.4.0 or 1.123.12 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 Cross-site Scripting (XSS) vulnerability existed in a markdown rendering component used in n8n's interface, including workflow sticky notes and other areas that support markdown content. An authenticated user with permission to create or modify workflows could abuse this to execute scripts with same-origin privileges when other users interact with a maliciously crafted workflow. This could lead to session hijacking and account takeover. Patches The issue has been fixed in n8n versions 2.2.1 and 1.123.9. 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: - Limit workflow creation and editing permissions to fully trusted users only. - Review existing workflows for potentially malicious markdown content in sticky notes and other components. - Educate users about the risks of opening workflows from untrusted sources. These…
Recommended action: Upgrade to 2.2.1 or 1.123.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Vulnerabilities in the Git node allowed authenticated users with permission to create or modify workflows to execute arbitrary system commands or read arbitrary files on the n8n host. Patches The issue has been fixed in n8n versions 2.5.0, and 1.123.10. 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: - Limit workflow creation and editing permissions to fully trusted users only. - Restrict or disable access to the Git node if not essential for operations. - Deploy n8n in a hardened environment with restricted operating system privileges and network access to reduce the impact of potential exploitation. 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…
Recommended action: Upgrade to 2.5.0 or 1.123.10 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 vulnerability in the file access controls allows authenticated users with permission to create or modify workflows to read sensitive files from the n8n host system. This can be exploited to obtain critical configuration data and user credentials, leading to complete account takeover of any user on the instance. Patches The issue has been fixed in n8n version 1.123.18 and 2.5.0. 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: - Limit workflow creation and editing permissions to fully trusted users only. - Restrict access to nodes that interact with the file system, particularly the "Read/Write Files from Disk" and "Git" nodes. 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 ---…
Recommended action: Upgrade to 2.5.0 or 1.123.18 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 Cross-site Scripting (XSS) vulnerability has been identified in the handling of webhook responses and related HTTP endpoints. Under certain conditions, the Content Security Policy (CSP) sandbox protection intended to isolate HTML responses may not be applied correctly. An authenticated user with permission to create or modify workflows could abuse this to execute malicious scripts with same-origin privileges when other users interact with the crafted workflow. This could lead to session hijacking and account takeover. Patches The issue has been fixed in n8n versions 1.122.5 and 1.123.2. 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: - Limit workflow creation and editing permissions to fully trusted users only. - Never execute untrusted workflows. - Review workflows that receive data from via webhooks, forms, or MCP servers…
Recommended action: Upgrade to 1.123.2 or 1.122.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Additional exploits in the expression evaluation of n8n have been identified and patched following CVE-2025-68613. An authenticated user with permission to create or modify workflows could abuse crafted expressions in workflow parameters to trigger unintended system command execution on the host running n8n. Patches The issue has been fixed in n8n versions 1.123.17 and 2.5.2. 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: - Limit workflow creation and editing permissions to fully trusted users only. - Deploy n8n in a hardened environment with restricted operating system privileges and network access to reduce the impact of potential exploitation. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures. Resources - Best practices for securing n8n - Initial vulnerability…
Recommended action: Upgrade to 2.5.2 or 1.123.17 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 Command Injection vulnerability was identified in n8n’s community package installation functionality. The issue allowed authenticated users with administrative permissions to execute arbitrary system commands on the n8n host under specific conditions. Important context - Exploitation requires administrative access to the n8n instance. - The affected functionality is restricted to trusted users who are already permitted to install third-party community packages. - No unauthenticated or low-privilege exploitation is possible. - There is no evidence of exploitation in the wild. Because administrative users can already extend n8n with custom or community code, the vulnerability does not meaningfully expand the threat model beyond existing administrator capabilities. However, it represents a violation of secure coding practices and has therefore been addressed. Patches Users are advised to upgrade to n8n version 1.120.3 or later, which fully resolves the issue. As a general…
Recommended action: Upgrade to 1.120.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The use of Buffer.allocUnsafe() and Buffer.allocUnsafeSlow() in the task runner allowed untrusted code to allocate uninitialized memory. Such uninitialized buffers could contain residual data from within the same Node.js process (for example, data from prior requests, tasks, secrets, or tokens), resulting in potential information disclosure. Only authenticated users are able to execute code through Task Runners. This issue affected any deployment in which both of the following conditions were met: - Task Runners were enabled using N8NRUNNERSENABLED=true (default: false) - Code Node was enabled (default: true) Patches Access to unsafe Buffer functions has been removed from the task runner sandbox. All buffer allocations are now zero-filled by default. - Fixed in: 1.114.3 & 1.115.0 - Action: It is strongly recommended to upgrade to version ≥ 1.114.3 as soon as possible. Changes introduced in this patch include: - Routing all buffer allocations through Buffer.alloc (which…
Recommended action: Upgrade to 1.114.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
n8n contains a critical Remote Code Execution (RCE) vulnerability in its workflow Expression evaluation system. Expressions supplied by authenticated users during workflow configuration may be evaluated in an execution context that is not sufficiently isolated from the underlying runtime. An authenticated attacker could abuse this behavior to execute arbitrary code with the privileges of the n8n process. Successful exploitation may lead to full compromise of the affected instance, including unauthorized access to sensitive data, modification of workflows, and execution of system-level operations.
Recommended action: Upgrade to 2.5.1, 2.4.5 or 1.123.17 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 Webhook node’s IP whitelist validation performed partial string matching instead of exact IP comparison. As a result, an incoming request could be accepted if the source IP address merely contained the configured whitelist entry as a substring. This issue affected instances where workflow editors relied on IP-based access controls to restrict webhook access. Both IPv4 and IPv6 addresses were impacted. An attacker with a non-whitelisted IP could bypass restrictions if their IP shared a partial prefix with a trusted address, undermining the intended security boundary. Patches This issue has been patched in version 2.2.0. Users are advised to upgrade to v2.2.0 or later, where IP whitelist validation uses strict IP comparison logic rather than partial string matching. Workarounds Users unable to upgrade immediately should avoid relying solely on IP whitelisting for webhook security. Recommended mitigations include: - Adding authentication mechanisms such as shared secrets,…
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authentication bypass in the Stripe Trigger node allows unauthenticated parties to trigger workflows by sending forged Stripe webhook events. The Stripe Trigger creates and stores a Stripe webhook signing secret when registering the webhook endpoint, but incoming webhook requests were not verified against this secret. As a result, any HTTP client that knows the webhook URL could send a POST request containing a matching event type, causing the workflow to execute as if a legitimate Stripe event had been received. This issue affects n8n users who have active workflows using the Stripe Trigger node. An attacker could potentially fake payment or subscription events and influence downstream workflow behavior. The practical risk is reduced by the fact that the webhook URL contains a high-entropy UUID; however, authenticated n8n users with access to the workflow can view this webhook ID. Patches The issue has been fixed in n8n version 2.2.2. Users should upgrade to this version…
Recommended action: Upgrade to 2.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerability in n8n allows an attacker to access files on the underlying server through execution of certain form-based workflows. A vulnerable workflow could grant access to an unauthenticated remote attacker. This could result in exposure of sensitive information stored on the system and may enable further compromise depending on deployment configuration and workflow usage. Patches The issue has been fixed in n8n version 1.121.0. Users should upgrade to this version or later to remediate the vulnerability. Workarounds No official workarounds are available. As a temporary mitigation, users may restrict or disable publicly accessible webhook and form endpoints until upgrading.
Recommended action: Upgrade to 1.121.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact n8n is affected by an authenticated Remote Code Execution (RCE) vulnerability. Under certain conditions, an authenticated user may be able to cause untrusted code to be executed by the n8n service. This could result in full compromise of the affected instance. Both self-hosted and n8n Cloud instances are impacted. Patches The issue has been resolved in n8n version 1.121.3. Users are advised to upgrade to this version or later to fully address the vulnerability. Workarounds If upgrading is not immediately possible, administrators can reduce exposure by disabling the Git node and limiting access for untrusted users. References - n8n documentation: Blocking access to nodes
Recommended action: Upgrade to 1.121.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In self-hosted n8n instances where the Code node runs in legacy (non-task-runner) JavaScript execution mode, authenticated users with workflow editing access can invoke internal helper functions from within the Code node. This allows a workflow editor to perform actions on the n8n host with the same privileges as the n8n process, including: - Reading files from the host filesystem (subject to any file-access restrictions configured on the instance and OS/container permissions) - Writing files to the host filesystem (subject to the same restrictions) Starting with n8n version 1.2.1, access to files in the n8n home directory (.n8n) is blocked by default. However, this does not restrict access to other parts of the filesystem unless additional file access limitations are configured. Patches - Upgrade to n8n version 2.0.0 or later, where task runners are enabled by default for Code node execution. - On n8n version 1.71.0 and above, enable task runners by setting…
Recommended action: Upgrade to 2.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A sandbox bypass vulnerability exists in the Python Code Node that uses Pyodide. An authenticated user with permission to create or modify workflows can exploit this vulnerability to execute arbitrary commands on the host system running n8n, using the same privileges as the n8n process. Patches In n8n version 1.111.0, a task-runner-based native Python implementation was introduced as an optional feature, providing a more secure isolation model. To enable it, you need to configure the N8NRUNNERSENABLED and N8NNATIVEPYTHONRUNNER environment variables. This implementation became the default starting with n8n version 2.0.0. Workarounds - Disable the Code Node by setting the environment variable NODESEXCLUDE: "[\"n8n-nodes-base.code\"]" (Docs) - Disable Python support in the Code node by setting the environment variable N8NPYTHONENABLED=false, which was introduced in n8n version 1.104.0. - Configure n8n to use the task runner based Python sandbox via the N8NRUNNERSENABLED and…
Recommended action: Upgrade to 2.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A stored Cross-Site Scripting (XSS) vulnerability may occur in n8n when using the “Respond to Webhook” node. When this node responds with HTML content containing executable scripts, the payload may execute directly in the top-level window, rather than within the expected sandbox introduced in version 1.103.0. This behavior can enable a malicious actor with workflow creation permissions to execute arbitrary JavaScript in the context of the n8n editor interface. While session cookies (n8n-auth) are marked HttpOnly and cannot be directly exfiltrated, the vulnerability can facilitate Cross-Site Request Forgery (CSRF)-like actions from within the user’s authenticated session, potentially allowing: - Unauthorized reading of sensitive workflow data or execution history. - Unauthorized modification or deletion of workflows. - Insertion of malicious workflow logic or external data exfiltration steps. n8n instances that allow untrusted users to create workflows are particularly…
Recommended action: Upgrade to 1.114.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact n8n contains a critical Remote Code Execution (RCE) vulnerability in its workflow expression evaluation system. Under certain conditions, expressions supplied by authenticated users during workflow configuration may be evaluated in an execution context that is not sufficiently isolated from the underlying runtime. An authenticated attacker could abuse this behavior to execute arbitrary code with the privileges of the n8n process. Successful exploitation may lead to full compromise of the affected instance, including unauthorized access to sensitive data, modification of workflows, and execution of system-level operations. Patches This issue has been fixed in n8n v1.122.0. Users are strongly advised to upgrade to version 1.122.0 or later, which introduces additional safeguards to restrict expression evaluation. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Limit workflow creation and editing…
Recommended action: Upgrade to 1.121.1 or 1.120.4 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 Git node allows workflows to set arbitrary Git configuration values through the Add Config operation. When an attacker-controlled workflow sets core.hooksPath to a directory within the cloned repository containing a Git hook such as pre-commit, Git executes that hook during subsequent Git operations. Because Git hooks run as local system commands, this behavior can lead to arbitrary command execution on the underlying n8n host. Successful exploitation requires the ability to create or modify an n8n workflow that uses the Git node. Affected versions: ≥ 0.123.1 and < 1.119.2 Patches This issue has been patched in n8n version 1.119.2. All users running affected versions should upgrade to 1.119.2 or later. Workarounds If upgrading is not immediately possible, the following mitigations can reduce exposure: - Exclude the Git node (Docs). - Avoid cloning or interacting with untrusted repositories using the Git Node.
Recommended action: Upgrade to 1.119.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A remote code execution vulnerability exists in the Git Node component available in both Cloud and Self-Hosted versions of n8n. When a malicious actor clones a remote repository containing a pre-commit hook, the subsequent use of the Commit operation in the Git Node can inadvertently trigger the hook’s execution. This allows attackers to execute arbitrary code within the n8n environment, potentially compromising the system and any connected credentials or workflows. All users with workflows that utilize the Git Node to clone untrusted repositories are affected. Patches The vulnerability was addressed in v1.113.0 (n8n-io/n8n#19559), which introduces a new environment variable: N8NGITNODEDISABLEBAREREPOS. For self-hosted deployments, it is strongly recommended to set this variable to true to mitigate the risk of executing malicious Git hooks. Workarounds To reduce risk prior to upgrading: - Avoid cloning or interacting with untrusted repositories using the Git Node. - Disable or…
Recommended action: Upgrade to 1.113.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A stored Cross-Site Scripting (XSS) vulnerability was identified in the @n8n/n8n-nodes-langchain.chatTrigger node in n8n. If an authorized user configures the node with malicious JavaScript in the initialMessages field and enables public access, the script will be executed in the browser of anyone who visits the resulting public chat URL. This vulnerability could be exploited for phishing or to steal cookies or other sensitive data from users who access the public chat link, posing a security risk. Patches This issue has been patched in version 1.107.0 of n8n. Users should upgrade to version 1.107.0 or later. Workarounds Disabling the n8n-nodes-langchain.chatTrigger node (docs) References #18148
Recommended action: Upgrade to 1.107.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A symlink traversal vulnerability was discovered in the Read/Write File node in n8n. While the node attempts to restrict access to sensitive directories and files, it does not properly account for symbolic links (symlinks). An attacker with the ability to create symlinks—such as by using the Execute Command node—could exploit this to bypass the intended directory restrictions and read from or write to otherwise inaccessible paths. Users of n8n.cloud are not impacted. Patches Affected users should update to version 1.106.0 or later. Workarounds Until the patch is applied: - Disable or restrict access to the Execute Command node and any other nodes that allow arbitrary file system access. - Avoid using the Read/Write File node on untrusted paths or inputs that could be manipulated via symlinks.
Recommended action: Upgrade to 1.106.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A stored Cross-Site Scripting (XSS) vulnerability was identified in n8n, specifically in the Form Trigger node's HTML form element. An authenticated attacker can inject malicious HTML via an <iframe with a srcdoc payload that includes arbitrary JavaScript execution. The attacker can also inject malicious Javascript by using <video coupled <source using an onerror event. While using iframe or a combination of video and source tag, this vulnerability allows for Account Takeover (ATO) by exfiltrating n8n-browserId and session cookies from authenticated users who visit a maliciously crafted form. Using these tokens and cookies, an attacker can impersonate the victim and change account details such as email addresses, enabling full control over the account—especially if 2FA is not enabled. Patches The issue was addressed in PR #16329. Users should upgrade to version =1.98.2. Workarounds Apart from updating to the fixed version, n8n instance administrators can: - Configure a reverse…
Recommended action: Upgrade to 1.98.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authorization vulnerability was discovered in the /rest/executions/:id/stop endpoint of n8n. An authenticated user can stop workflow executions that they do not own or that have not been shared with them, leading to potential business disruption. Impact This is an improper authorization vulnerability. While most API methods enforce user-scoped access to workflow execution IDs, the /stop endpoint fails to do so. An attacker can guess or enumerate execution IDs (which are sequential and partially exposed via verbose error messages) and terminate active workflows initiated by other users. Who is impacted: - Environments where multiple users with varying trust levels share access to the same n8n instance. - All users running long-running or time-sensitive workflows (e.g., using the wait node). An attacker with authenticated access can exploit this flaw to: - Disrupt other users’ workflow executions. - Cause denial of service for business-critical automations. Patches The issue…
Recommended action: Upgrade to 1.99.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Denial of Service vulnerability in /rest/binary-data endpoint when processing empty filesystem URIs (filesystem:// or filesystem-v2://). Impact This is a Denial of Service (DoS) vulnerability that allows authenticated attackers to cause service unavailability through malformed filesystem URI requests. The vulnerability affects: - The /rest/binary-data endpoint - n8n.cloud instances (confirmed HTTP/2 524 timeout responses) Attackers can exploit this by sending GET requests with empty filesystem URIs (filesystem:// or filesystem-v2://) to the /rest/binary-data endpoint, causing resource exhaustion and service disruption. Patches The issue has been patched in 1.99.0. All users should upgrade to this version or later. The fix introduces strict checking of URI patterns. Patch commit: https://github.com/n8n-io/n8n/pull/16229
Recommended action: Upgrade to 1.99.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.