CVE-2026-92587 in n8n
Summary
by MITRE • 09/17/2026
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 N8N_RESTRICT_FILE_ACCESS_TO 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 NODES_EXCLUDE.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in n8n workflow automation platforms prior to versions 1.123.76, 2.37.7, and 2.38.2 represents a critical path traversal flaw within the Git integration node that allows authenticated users to bypass file access restrictions. This security issue stems from an inconsistency between how the application validates remote repository paths and how the underlying git command-line tool resolves them. Specifically, when processing a relative URL for a remote repository, n8n performs a validation check against a configured repositoryPath intended to restrict file access to specific directories defined by the N8N_RESTRICT_FILE_ACCESS_TO environment variable. However, after this initial validation passes, the application invokes the git binary using that same path as its working directory. Git inherently resolves relative URLs from the current working directory context, which can lead it to traverse up the filesystem hierarchy to the enclosing repository's top level before resolving the remote URL string.
This discrepancy creates a sandbox escape scenario where an authenticated user with member-level privileges can exploit this logic error by nesting their target repository one level below the configured path. By doing so, they construct a relative URL that appears valid under n8n’s initial file-access check because it aligns with the restricted directory structure from the application's perspective. Yet, when git executes and resolves the same relative string from its actual working directory context, it interprets the path differently, effectively walking up to resolve the reference outside the intended sandbox boundaries. This allows the user to fetch or pull data from a git repository that lies beyond the permitted access scope, thereby circumventing the security controls designed to limit file system exposure.
The operational impact of this vulnerability is significant as it enables unauthorized reading and merging of external repository objects into the user's own n8n workspace. Once an attacker successfully pulls content from an unrestricted or sensitive repository, those contents become accessible within the application environment where they can be read back by the user or potentially leveraged in subsequent workflow executions. This not only violates data confidentiality but also introduces risks related to supply chain integrity if malicious code is introduced into the n8n instance through this mechanism. The flaw essentially undermines the principle of least privilege and file access restrictions, allowing lateral movement across filesystem boundaries that should remain isolated based on user permissions and configuration settings.
To mitigate this risk, users must upgrade to patched versions of n8n, specifically version 1.123.76 or later for major releases prior to v2, and version 2.37.7 or 2.38.2 for the latest release lines. These updates correct the vulnerability by ensuring that remote references are resolved from the actual directory in which git operates before applying any sandbox checks, thereby aligning application logic with system-level path resolution behavior. For organizations unable to immediately patch their environments, a temporary workaround involves disabling the Git node entirely by adding n8n-nodes-base.git to the NODES_EXCLUDE environment variable configuration. This prevents execution of the vulnerable code path until an upgrade can be performed.
From a classification perspective, this vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, commonly known as directory traversal or path traversal. The attack vector involves authenticated users exploiting logic errors in input validation and command execution contexts. In terms of the MITRE ATT&CK framework, this behavior is consistent with techniques involving resource hijacking or unauthorized access to system resources, specifically falling under tactics related to Collection if data exfiltration occurs via read-back operations, or Execution if the merged content leads to further compromise through workflow automation chains. Security teams should prioritize patching these instances and review audit logs for any signs of unusual git fetch or pull activities originating from member accounts in affected versions.