GHSA-gf29-4f56-r2jf: n8n Git node bypass leaks

Q: Is GHSA-gf29-4f56-r2jf actively exploited?

No confirmed active exploitation of GHSA-gf29-4f56-r2jf has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-gf29-4f56-r2jf?

Upgrade n8n to 1.123.67, 2.31.5, or 2.32.1 as soon as possible — this is the only complete remediation. If immediate patching isn't feasible, restrict n8n instance access to fully trusted users only, and/or disable the Git node entirely by adding n8n-nodes-base.git to the NODES_EXCLUDE environment variable (both are advisory-recommended stopgaps, not full fixes). For detection, audit existing workflow definitions and execution logs for Git node fetch/pull/push-tags steps whose configured remote value resolves to a local filesystem path (file:// URIs, relative paths, or path-traversal sequences like ../) rather than a legitimate remote URL. Review who currently holds workflow create/execute permissions and tighten the permission model if it extends to semi-trusted users such as contractors.

Q: What systems are affected by GHSA-gf29-4f56-r2jf?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration pipelines.

Q: What is the CVSS score for GHSA-gf29-4f56-r2jf?

No CVSS score has been assigned yet.

CISO Take

This is a path traversal flaw (CWE-22) in n8n's Git node: authenticated users with workflow create/execute rights can point the fetch, pull, or push-tags operations at a local filesystem path instead of a real remote, sidestepping the repository-path containment checks that already protect the clone and push operations, then use that access to pull an arbitrary local git repository into their workspace and read its files and commit history. The blast radius is real but bounded — n8n has 16 tracked downstream dependents and an OpenSSF Scorecard of 6.6/10, and this affects any deployment where workflow-authoring rights are handed to users who aren't fully trusted, which is common in shared or multi-tenant n8n instances used for agentic automation. There's no CVSS score, EPSS data, CISA KEV listing, public exploit, or Nuclei template available, so this is not actively exploited or trivially scannable — the barrier is authenticated access plus moderate technical understanding of the containment bypass, not zero-day tooling. Action: patch to n8n 1.123.67, 2.31.5, or 2.32.1; if you can't patch immediately, restrict instance access to fully trusted users and/or set NODES_EXCLUDE=n8n-nodes-base.git to disable the node, and audit workflow definitions for Git node remote values pointing at local paths (file://, relative paths, ../) as a detection signal.

Sources: GitHub Advisory OpenSSF ATLAS

What is the risk?

Severity is rated high by the advisory but lacks a published CVSS vector, EPSS score, or KEV listing, so exploitation likelihood cannot be quantified numerically — treat it as moderate-to-high risk based on qualitative factors instead. Exploitability requires an authenticated n8n account with workflow create/execute rights (not unauthenticated remote access), which limits the attacker population to insiders, compromised low-privilege accounts, or malicious contractors in shared instances. Once that bar is met, exploitation is low-complexity: the fix confirms fetch/pull/push-tags simply lacked the same path-containment validation already applied to clone/push, meaning no novel research or AI-specific tradecraft is required. Impact is confined to information disclosure (arbitrary local repo files and history) rather than remote code execution, but that history can itself contain credentials, tokens, or other tenants' data.

How does the attack unfold?

Initial Access

Attacker obtains or already holds an authenticated n8n account with workflow create/execute rights, e.g. as a contractor or low-privilege insider on a shared instance.

Tool Abuse

Attacker configures a workflow's Git node fetch, pull, or push-tags operation with a remote value pointing at a local filesystem path, bypassing the containment check.

AML.T0053

Data Access

The arbitrary local git repository is pulled into the attacker's workspace, exposing its files and full commit history for reading.

AML.T0037

Impact

Attacker extracts secrets, source code, or other tenants' data embedded in the pulled repository's files or history.

Initial Access

Attacker obtains or already holds an authenticated n8n account with workflow create/execute rights, e.g. as a contractor or low-privilege insider on a shared instance.

Tool Abuse

Attacker configures a workflow's Git node fetch, pull, or push-tags operation with a remote value pointing at a local filesystem path, bypassing the containment check.

AML.T0053

Data Access

The arbitrary local git repository is pulled into the attacker's workspace, exposing its files and full commit history for reading.

AML.T0037

Impact

Attacker extracts secrets, source code, or other tenants' data embedded in the pulled repository's files or history.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.67	`1.123.67`
206.1K OpenSSF 6.7 Pushed 5d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade n8n to 1.123.67, 2.31.5, or 2.32.1 as soon as possible — this is the only complete remediation. If immediate patching isn't feasible, restrict n8n instance access to fully trusted users only, and/or disable the Git node entirely by adding n8n-nodes-base.git to the NODES_EXCLUDE environment variable (both are advisory-recommended stopgaps, not full fixes). For detection, audit existing workflow definitions and execution logs for Git node fetch/pull/push-tags steps whose configured remote value resolves to a local filesystem path (file:// URIs, relative paths, or path-traversal sequences like ../) rather than a legitimate remote URL. Review who currently holds workflow create/execute permissions and tighten the permission model if it extends to semi-trusted users such as contractors.

How is it classified?

Auth Bypass Data Leakage Agent Plugin AML.T0037 - Data from Local System AML.T0053 - AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF

MANAGE 2.3 - Third-party AI resources and components are monitored and managed

OWASP LLM Top 10

LLM06 - Sensitive Information Disclosure LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is GHSA-gf29-4f56-r2jf?

This is a path traversal flaw (CWE-22) in n8n's Git node: authenticated users with workflow create/execute rights can point the fetch, pull, or push-tags operations at a local filesystem path instead of a real remote, sidestepping the repository-path containment checks that already protect the clone and push operations, then use that access to pull an arbitrary local git repository into their workspace and read its files and commit history. The blast radius is real but bounded — n8n has 16 tracked downstream dependents and an OpenSSF Scorecard of 6.6/10, and this affects any deployment where workflow-authoring rights are handed to users who aren't fully trusted, which is common in shared or multi-tenant n8n instances used for agentic automation. There's no CVSS score, EPSS data, CISA KEV listing, public exploit, or Nuclei template available, so this is not actively exploited or trivially scannable — the barrier is authenticated access plus moderate technical understanding of the containment bypass, not zero-day tooling. Action: patch to n8n 1.123.67, 2.31.5, or 2.32.1; if you can't patch immediately, restrict instance access to fully trusted users and/or set NODES_EXCLUDE=n8n-nodes-base.git to disable the node, and audit workflow definitions for Git node remote values pointing at local paths (file://, relative paths, ../) as a detection signal.

Is GHSA-gf29-4f56-r2jf actively exploited?

No confirmed active exploitation of GHSA-gf29-4f56-r2jf has been reported, but organizations should still patch proactively.

How to fix GHSA-gf29-4f56-r2jf?

Upgrade n8n to 1.123.67, 2.31.5, or 2.32.1 as soon as possible — this is the only complete remediation. If immediate patching isn't feasible, restrict n8n instance access to fully trusted users only, and/or disable the Git node entirely by adding n8n-nodes-base.git to the NODES_EXCLUDE environment variable (both are advisory-recommended stopgaps, not full fixes). For detection, audit existing workflow definitions and execution logs for Git node fetch/pull/push-tags steps whose configured remote value resolves to a local filesystem path (file:// URIs, relative paths, or path-traversal sequences like ../) rather than a legitimate remote URL. Review who currently holds workflow create/execute permissions and tighten the permission model if it extends to semi-trusted users such as contractors.

What systems are affected by GHSA-gf29-4f56-r2jf?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration pipelines.

What is the CVSS score for GHSA-gf29-4f56-r2jf?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation / orchestration pipelines

MITRE ATLAS Techniques

AML.T0037 Data from Local System

AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM06, LLM07

What are the technical details?

Original Advisory

## Impact Authenticated n8n users with workflow create/execute rights could use the Git node's fetch, pull, or push-tags operations to bypass the repository-path containment checks that already protected clone and push. By pointing an allowlisted remote configuration value at a local path outside the intended sandbox, an attacker could pull an arbitrary local git repository into the workspace and subsequently read its files and history. ## Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability. ## Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict n8n instance access to fully trusted users only. - Disable the Git node by adding `n8n-nodes-base.git` to the `NODES_EXCLUDE` environment variable. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Exploitation Scenario

A contractor or low-trust employee with workflow create/execute rights on a shared n8n instance builds a workflow using the Git node's pull operation, but instead of a normal git remote URL, sets the remote configuration value to a local filesystem path pointing outside their intended workspace sandbox — something the patched containment checks would now block on fetch/pull/push-tags just as they already did on clone/push. n8n pulls that arbitrary local repository into the attacker's own workflow workspace, after which the attacker uses further Git node operations to browse its files and full commit history, extracting secrets, source code, or another tenant's data that should never have been reachable from their account.

Weaknesses (CWE)

CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Primary

CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.