CVE-2026-49465: n8n Path Traversal Bypass in Git Node File Sandbox

Technical summary

The vulnerability exists in n8n's Git node implementation, specifically in the Clone and Push operations. When a user provides a local filesystem path as the source or target repository instead of a remote Git URL, the application fails to properly validate the path against its file access sandbox. The N8N_RESTRICT_FILE_ACCESS_TO environment variable is designed to limit file system access, but this validation is bypassed when paths are specified through Git operations. An authenticated workflow creator can construct a workflow that clones a restricted local git repository into an allowed path, effectively circumventing the intended access control mechanism. The vulnerability is classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and has a CVSS 3.1 score of 7.7 (High severity) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, indicating network-accessible exploitation requiring low attack complexity and authenticated user privileges, with confidentiality impact across system boundaries.

Business impact

Organizations running n8n for workflow automation face potential unauthorized disclosure of sensitive repository data. Attackers with workflow creation privileges could extract credentials, source code, configuration files, or other secrets stored in accessible git repositories. In environments where n8n runs with elevated process permissions or has access to shared repository storage, this could expose enterprise intellectual property, API keys, deployment configurations, or other confidential information. The impact is primarily confidentiality-focused; the vulnerability does not enable data modification or service disruption. Multi-tenant n8n installations are particularly at risk if user isolation relies solely on file path restrictions.

Affected systems

n8n versions prior to 1.123.48 (legacy/1.x branch), 2.21.8 (2.21.x branch), and 2.22.4 (2.22.x branch) are vulnerable. The vulnerability requires an authenticated user account with permissions to create or modify workflows. The exposure is contingent on the n8n process having access to local git repositories outside the intended sandbox; organizations running n8n in isolated containers with minimal filesystem access may have reduced exposure. Self-hosted deployments are directly affected; SaaS offerings depend on provider deployment practices.

Exploitability

Exploitation requires valid n8n credentials and workflow modification permissions, making this an authenticated attack vector. There is no known public exploit code, and the vulnerability does not appear on the CISA KEV list. An internal user or compromised account with workflow access can exploit this in a single operation by creating a workflow with a malicious Git node configuration. The attack is deterministic and reliable once an attacker knows the local path to a sensitive repository. External attackers must first obtain valid authentication, making this primarily an insider threat or post-compromise lateral movement scenario.

Remediation

Upgrade n8n to patched versions: 1.123.48 or later for the 1.x branch, 2.21.8 or later for the 2.21.x branch, or 2.22.4 or later for the 2.22.x branch. The patches implement proper path validation for Git node operations to prevent local filesystem paths from bypassing the file access sandbox. After upgrading, verify that the N8N_RESTRICT_FILE_ACCESS_TO configuration remains in place and is properly enforced. No workaround is available for unpatched versions; isolation through restrictive process permissions and filesystem access controls can reduce but not eliminate risk.

Patch guidance

Prioritize patching production n8n deployments immediately. The fix is available across multiple supported versions (1.x and 2.x branches), so determine your current version and upgrade to the next patched release in your branch. Test the upgrade in a staging environment to confirm workflow functionality remains intact and that file access restrictions continue to operate as expected. If you are on an unsupported version below 1.123.48 or in the 2.x series below 2.21.8, plan an upgrade path. Document your file sandbox configuration (N8N_RESTRICT_FILE_ACCESS_TO) before and after patching to ensure continuity of access controls.

Detection guidance

Monitor workflow definitions for Git nodes that reference local filesystem paths (e.g., 'file://', '/path/to/repo', or absolute paths) instead of remote URLs. Audit user accounts with workflow creation or modification permissions; identify accounts that may pose insider risk. Review n8n logs for Git node operations, particularly Clone and Push actions that reference local paths. In network-isolated environments, monitor file system access patterns from n8n processes to detect attempts to read from unintended directories. If possible, enable audit logging of workflow changes to detect suspicious modifications. SIEM rules can flag workflows containing Git nodes with file:// URIs or absolute local paths.

Why prioritize this

This vulnerability merits urgent patching due to its high CVSS score (7.7), direct impact on data confidentiality, and ease of exploitation by authenticated users. The bypass of an intentional sandbox mechanism represents a security control escape. Although it requires authentication, the low attack complexity and wide scope (system boundary impact) make it a significant risk, particularly in environments where workflow permissions are broadly granted or where users have access to sensitive repositories. Organizations should treat this as a priority patch unless they can confirm n8n has no access to sensitive git repositories.

Risk score, explained

The CVSS 3.1 High score of 7.7 reflects a network-accessible vulnerability (AV:N) with low attack complexity (AC:L) that requires authentication (PR:L) but does not require user interaction (UI:N). The scope changes across security boundaries (S:C), and confidentiality is severely impacted (C:H), while integrity and availability are unaffected (I:N/A:N). This scoring appropriately reflects the practical risk: authenticated attackers can reliably extract sensitive data from normally protected paths, but the requirement for valid credentials prevents mass exploitation and keeps the score in the High rather than Critical range.

Frequently asked questions