CVE-2026-86995 in n8n
Summary
by MITRE • 09/09/2026
n8n is an open source workflow automation platform. Prior to 1.123.76, 2.37.7, and 2.38.2, the Git node validated the repository parameter for fetch or pull, but setUpstream wrote a branch..remote value into repository configuration without validating it. A later fetch or pull resolved the remote from that configuration instead of the checked parameter. An authenticated workflow editor could therefore point Git at any local repository readable by the n8n process and receive its contents through packages/nodes-base/nodes/Git/GenericFunctions.ts. This issue is fixed in versions 1.123.76, 2.37.7 and 2.38.2.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified within the n8n workflow automation platform represents a critical logic flaw in how Git operations are handled during repository synchronization tasks. Specifically, this issue affects versions prior to 1.123.76 for the legacy branch and prior to 2.37.7 and 2.38.2 for newer releases. The core of the problem lies in an inconsistency between parameter validation and configuration writing within the Git node implementation. When a user initiates a fetch or pull operation, the system correctly validates the repository parameter provided by the workflow editor to ensure it points to a permitted location. However, during the setup phase where upstream remote configurations are written into local git settings, the application fails to validate the branch.remote value being stored in the configuration file. This discrepancy creates a state where the initial check is bypassed for subsequent operations that rely on this persisted configuration rather than the original input parameter.
From an operational perspective, this flaw allows an authenticated workflow editor to manipulate the underlying Git client behavior by injecting arbitrary values into the local repository's remote configuration. Because n8n typically runs with specific file system permissions, any local repository readable by the process user becomes accessible through this mechanism. An attacker can exploit this by crafting a malicious workflow that sets up a git upstream pointing to an internal or sensitive local path. Subsequent fetch or pull actions will then resolve against this manipulated configuration rather than the originally validated parameter, effectively bypassing access controls and allowing the extraction of source code, secrets, or other data stored in those repositories. This constitutes a severe information disclosure risk that could lead to further compromise if sensitive credentials are found within the accessed files.
This vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to properly validate all inputs used in constructing system commands or configuration states. Furthermore, it relates to CWE-94 Code Injection via Git operations, where user-controlled data influences the execution of external programs without adequate sanitization. In terms of MITRE ATT&CK framework classification, this behavior is consistent with T1083 File and Directory Discovery, as an attacker can enumerate and access local file systems through the application's privileged context. It also touches upon T1552 Unsecured Credentials if sensitive data such as API keys or passwords are stored in the accessed repositories. The exploitation requires authentication, which limits the attack surface to compromised accounts or insider threats with workflow editing privileges.
To mitigate this vulnerability, organizations must immediately upgrade n8n to version 1.123.76, 2.37.7, or 2.38.2 and later, where the validation logic has been corrected to ensure that all parameters influencing git configuration are subject to rigorous checking before being written to disk. Additionally, administrators should enforce strict least-privilege principles for the n8n process user account on the host operating system. By restricting file system permissions so that the application cannot read sensitive directories or repositories outside of its designated working area, the impact of this vulnerability is significantly reduced even if an attacker manages to trigger the flawed logic. Regular auditing of workflow definitions and monitoring for unusual git operations can also provide early detection indicators for potential exploitation attempts in environments where upgrading may be delayed due to compatibility concerns.