GHSA-rcv6-pvrj-4xcg: n8n Git node RCE

Q: Is GHSA-rcv6-pvrj-4xcg actively exploited?

No confirmed active exploitation of GHSA-rcv6-pvrj-4xcg has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-rcv6-pvrj-4xcg?

1) Upgrade to n8n 1.123.67, 2.31.5, 2.32.1, or later — this is the only full remediation. 2) If immediate patching isn't possible, disable the Git node by setting `NODES_EXCLUDE=n8n-nodes-base.git` in the environment. 3) Restrict workflow creation/execution rights to fully trusted users only; treat that permission as equivalent to code-execution access on the host. 4) Restrict network egress from the n8n instance to limit what an attacker can reach if RCE is achieved. 5) For detection, monitor process execution and git hook invocations (post-checkout, post-merge, pre-commit, etc.) spawned by the n8n process, and audit workflow definitions for Git nodes pointing at unexpected or externally-controlled repository paths.

Q: What systems are affected by GHSA-rcv6-pvrj-4xcg?

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

Q: What is the CVSS score for GHSA-rcv6-pvrj-4xcg?

No CVSS score has been assigned yet.

CISO Take

A newly disclosed n8n vulnerability lets any authenticated user with workflow creation rights achieve remote code execution on the n8n host by staging a crafted local git repository whose hooks fire when the built-in Git node clones or checks it out, running arbitrary commands as the n8n process user. This matters because n8n is an AI agent orchestration platform with 16 tracked downstream dependents and a package risk score of 69/100, and because n8n workflows routinely hold LLM API keys, database credentials, and connections to other agentic tools — a single malicious workflow can pivot from code execution into a broader credential-theft or supply-chain incident across both self-hosted and cloud deployments. There is no CISA KEV listing, no public exploit or Nuclei template, and no EPSS score published, so this is not yet under active exploitation, but the bar to trigger it is low: any user permitted to build and run workflows, a common permission level in collaborative automation teams. Patch to n8n 1.123.67, 2.31.5, or 2.32.1 immediately; if patching must wait, disable the Git node via `NODES_EXCLUDE=n8n-nodes-base.git`, restrict who can create/execute workflows, and tighten egress from the n8n host as compensating controls.

Sources: GitHub Advisory ATLAS OpenSSF

What is the risk?

High-severity RCE with a low technical bar (default git hook behavior, no memory corruption or novel exploitation needed) but gated behind an authentication and authorization requirement — the attacker must already hold workflow create/execute rights in n8n. No CISA KEV listing, no EPSS score, and no public exploit or scanner template exist yet, so exploitation-in-the-wild risk is currently low but the blast radius once triggered is severe: full command execution as the n8n process user on an automation platform that typically holds numerous downstream API keys and agent credentials (16 tracked dependents, OpenSSF Scorecard 6.6/10, 166 other CVEs recorded against the n8n package historically). Any organization allowing semi-trusted or lower-privilege users to author workflows — a common pattern in self-serve automation and citizen-developer setups — should treat this as urgent-but-not-emergency: patch on the next maintenance window, and apply the NODES_EXCLUDE workaround immediately if that window is more than a few days out.

How does the attack unfold?

Stage malicious repository

Attacker with n8n workflow creation rights prepares a local git repository containing a malicious hook script (e.g. post-checkout).

AML.T0079

Invoke Git node

Attacker builds and runs an n8n workflow whose Git node clones or checks out the crafted repository.

AML.T0053

Hook execution

Under default git security settings, the checkout triggers the malicious hook, running arbitrary OS commands as the n8n process user.

AML.T0050

Host and credential compromise

Attacker uses the resulting shell to read n8n-stored credentials (LLM API keys, DB secrets) and pivot to systems reachable from the n8n host.

AML.T0112.000

Stage malicious repository

Attacker with n8n workflow creation rights prepares a local git repository containing a malicious hook script (e.g. post-checkout).

AML.T0079

Invoke Git node

Attacker builds and runs an n8n workflow whose Git node clones or checks out the crafted repository.

AML.T0053

Hook execution

Under default git security settings, the checkout triggers the malicious hook, running arbitrary OS commands as the n8n process user.

AML.T0050

Host and credential compromise

Attacker uses the resulting shell to read n8n-stored credentials (LLM API keys, DB secrets) and pivot to systems reachable from the n8n host.

AML.T0112.000

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

1) Upgrade to n8n 1.123.67, 2.31.5, 2.32.1, or later — this is the only full remediation. 2) If immediate patching isn't possible, disable the Git node by setting NODES_EXCLUDE=n8n-nodes-base.git in the environment. 3) Restrict workflow creation/execution rights to fully trusted users only; treat that permission as equivalent to code-execution access on the host. 4) Restrict network egress from the n8n instance to limit what an attacker can reach if RCE is achieved. 5) For detection, monitor process execution and git hook invocations (post-checkout, post-merge, pre-commit, etc.) spawned by the n8n process, and audit workflow definitions for Git nodes pointing at unexpected or externally-controlled repository paths.

How is it classified?

Code Execution Supply Chain Agent Plugin AML.T0050 - Command and Scripting Interpreter AML.T0053 - AI Agent Tool Invocation AML.T0112.000 - Local AI Agent

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - AI system security

OWASP LLM Top 10

LLM05:2025 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is GHSA-rcv6-pvrj-4xcg?

A newly disclosed n8n vulnerability lets any authenticated user with workflow creation rights achieve remote code execution on the n8n host by staging a crafted local git repository whose hooks fire when the built-in Git node clones or checks it out, running arbitrary commands as the n8n process user. This matters because n8n is an AI agent orchestration platform with 16 tracked downstream dependents and a package risk score of 69/100, and because n8n workflows routinely hold LLM API keys, database credentials, and connections to other agentic tools — a single malicious workflow can pivot from code execution into a broader credential-theft or supply-chain incident across both self-hosted and cloud deployments. There is no CISA KEV listing, no public exploit or Nuclei template, and no EPSS score published, so this is not yet under active exploitation, but the bar to trigger it is low: any user permitted to build and run workflows, a common permission level in collaborative automation teams. Patch to n8n 1.123.67, 2.31.5, or 2.32.1 immediately; if patching must wait, disable the Git node via `NODES_EXCLUDE=n8n-nodes-base.git`, restrict who can create/execute workflows, and tighten egress from the n8n host as compensating controls.

Is GHSA-rcv6-pvrj-4xcg actively exploited?

No confirmed active exploitation of GHSA-rcv6-pvrj-4xcg has been reported, but organizations should still patch proactively.

How to fix GHSA-rcv6-pvrj-4xcg?

1) Upgrade to n8n 1.123.67, 2.31.5, 2.32.1, or later — this is the only full remediation. 2) If immediate patching isn't possible, disable the Git node by setting `NODES_EXCLUDE=n8n-nodes-base.git` in the environment. 3) Restrict workflow creation/execution rights to fully trusted users only; treat that permission as equivalent to code-execution access on the host. 4) Restrict network egress from the n8n instance to limit what an attacker can reach if RCE is achieved. 5) For detection, monitor process execution and git hook invocations (post-checkout, post-merge, pre-commit, etc.) spawned by the n8n process, and audit workflow definitions for Git nodes pointing at unexpected or externally-controlled repository paths.

What systems are affected by GHSA-rcv6-pvrj-4xcg?

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

What is the CVSS score for GHSA-rcv6-pvrj-4xcg?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworkslow-code AI automation pipelinesworkflow orchestration platforms

MITRE ATLAS Techniques

AML.T0050 Command and Scripting Interpreter

AML.T0053 AI Agent Tool Invocation

AML.T0112.000 Local AI Agent

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

OWASP LLM Top 10: LLM05:2025

What are the technical details?

Original Advisory

## Impact Authenticated n8n users with rights to create and execute workflows could achieve code execution on the n8n host. Using the Git node, under the default `git` security settings, by staging a crafted local repository, an attacker could cause `git` to run hooks, executing arbitrary commands as the n8n process user. Both self-hosted and cloud instances are affected where authenticated users can create and execute workflows using the Git node. ## 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. - Restrict network egress from the n8n instance to limit the impact of arbitrary code execution. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Exploitation Scenario

An attacker who has (or obtains, e.g. via a compromised low-privilege account) rights to create and execute n8n workflows stages a local git repository containing a malicious hook script — for example a `post-checkout` hook that executes a reverse shell or downloads a second-stage payload. They build an n8n workflow using the Git node configured to clone or check out that repository. When the workflow runs, n8n's default git security settings allow the hook to execute, running arbitrary OS commands as the n8n process user. From there the attacker can read credentials stored in n8n's credential vault (LLM API keys, database secrets, connected SaaS tokens), pivot to other systems reachable from the n8n host, or tamper with other automation workflows to establish persistence.

Weaknesses (CWE)

CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') Primary

CWE-78 — Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'): The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.

[Architecture and Design] If at all possible, use library calls rather than external processes to recreate the desired functionality.
[Architecture and Design, Operation] Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.