CVE-2026-103254 in n8n
Summary
by MITRE • 10/01/2026
n8n versions before 1.123.80, from 2.0.0 before 2.39.6, and from 2.40.0 before 2.40.1 contain a path traversal vulnerability in signed resume URL generation for Send-and-Wait approvals. Attackers with workflow creation permissions can mint valid approval URLs for gates in projects they cannot access by exploiting unresolved traversal sequences in caller-controlled node IDs, enabling cross-project approval forgery.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/01/2026
The identified security flaw resides within the n8n automation platform across multiple version ranges, specifically affecting versions prior to 1.123.80, as well as the 2.x series from 2.0.0 up to but not including 2.39.6 and from 2.40.0 up to but not including 2.40.1. This vulnerability is classified as a path traversal issue that manifests during the generation of signed resume URLs for Send-and-Wait approval gates. The core technical deficiency lies in the handling of caller-controlled node identifiers when constructing these cryptographic signatures and URL paths. Instead of strictly validating or sanitizing the input to ensure it corresponds only to nodes within the authorized project scope, the application fails to adequately resolve traversal sequences embedded within the node ID parameter. This oversight allows an attacker to manipulate the internal path resolution logic, effectively bypassing access control checks that are supposed to restrict approval actions to specific projects and workflows.
From a technical perspective, this flaw represents a classic case of insecure direct object references combined with improper input validation. When a workflow containing a Send-and-Wait node is configured, n8n generates a unique URL signed with cryptographic keys to allow users to approve or reject the pending action. The system relies on the integrity of the node identifier included in this process to determine which project and workflow context applies. By injecting path traversal characters into the node ID field during workflow creation, an attacker can alter the resolved target of the approval mechanism. Because the signature generation does not strictly bind the token to a whitelisted set of valid nodes within the creator's permitted projects, the resulting URL becomes valid for gates located in other projects where the attacker lacks any permissions or visibility. This breaks the fundamental security boundary between isolated project spaces within the multi-tenant architecture of n8n instances.
The operational impact of this vulnerability is significant for organizations relying on strict access controls and audit trails. An authenticated user with workflow creation privileges, which may be a relatively low-level permission in many configurations, can forge approval tokens for gates they are not authorized to interact with. This capability enables cross-project approval forgery, allowing the attacker to approve or reject automated processes belonging to other teams or departments without detection through standard access logs alone. Such actions could lead to unauthorized execution of downstream workflows, potential data exfiltration if those workflows involve sensitive operations, and a complete breakdown of integrity controls within the automation pipeline. The ability to manipulate approval states undermines trust in the workflow engine's reliability and can facilitate further lateral movement or privilege escalation depending on the capabilities exposed by the compromised gates.
This vulnerability aligns with CWE-22 Improper Limitation of a Pathname to a Restricted Directory, as it involves manipulating input to access resources outside intended boundaries, albeit applied here to logical project scopes rather than file system directories. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, where an attacker uses legitimate credentials and permissions to perform actions beyond their authorized scope, specifically leveraging the workflow creation capability as a vector for privilege abuse. To mitigate this risk, organizations must immediately upgrade n8n to version 1.123.80 or later in the legacy branch, or versions 2.39.6 and 2.40.1 and newer in the current release line. These updates contain patches that enforce strict validation of node identifiers during signature generation, ensuring that only nodes explicitly belonging to accessible projects can be targeted by generated approval URLs. Additionally, administrators should review workflow creation permissions within their instances, applying the principle of least privilege to restrict who can define complex automation flows until all systems are fully patched.