CVE-2026-72767: n8n: Git node RCE via malicious repo hooks

UNKNOWN
Published August 11, 2026
CISO Take

CVE-2026-72767 is a remote code execution flaw in n8n's Git node: any authenticated user who can create and run workflows can stage a malicious local Git repository whose hooks fire under default git security settings, executing arbitrary commands as the n8n process user. This matters because n8n is widely deployed as an AI agent orchestration layer holding credentials, API keys, and integration secrets — a single crafted workflow can pivot from a low-privilege account into full host or cloud-tenant compromise, not just a contained script error. Exploitation pressure is currently moderate rather than acute: EPSS sits at 0.39% (top 68th percentile), the flaw is not in CISA KEV, no public exploit or Nuclei template exists, and CISA's SSVC decision is the lowest urgency tier, 'Track' — but authenticated RCE via a common developer primitive (git hooks) is trivial to weaponize once someone has workflow-creation rights, whether a malicious insider or a compromised low-privilege account. Upgrade immediately to n8n 1.123.67, 2.31.5, or 2.32.1; until patched, restrict who can create/execute workflows using the Git node and monitor for unexpected child processes or git hook execution under the n8n service account.

Sources: NVD GitHub Advisory EPSS ATLAS VulnCheck

What is the risk?

Impact is critical — successful exploitation yields arbitrary command execution as the n8n process user, which in most deployments has broad reach into stored credentials, connected integrations, and the underlying host or container. Exploitability is gated by an authentication and authorization precondition (the attacker needs workflow create/execute rights), which lowers the pool of potential attackers to insiders, compromised low-privilege accounts, or anyone abusing lax role assignment — but the technique itself (staging a git repo with malicious hooks) requires no novel research and is well-documented tradecraft, so once an account is available exploitation is straightforward. Current threat signals (no KEV listing, no public PoC, SSVC 'Track', moderate EPSS) indicate this is not yet under active mass exploitation, but the CWE-78 command injection class and the affected population (all self-hosted and cloud n8n instances below the patched versions) make this a high-priority patch item rather than a monitor-only issue.

How does the attack unfold?

Initial Access
Attacker authenticates to n8n with an account (or compromised account) that has rights to create and execute workflows.
AML.T0012
Staging
Attacker crafts a local Git repository with hook scripts configured to run under default git security settings and stages it for the Git node.
AML.T0079
Execution
The workflow's Git node performs a clone/pull/checkout against the crafted repository, triggering git hook execution and running attacker-controlled commands as the n8n process user.
AML.T0050
Impact
Attacker achieves code execution on the host or cloud tenant, enabling credential theft from n8n's secrets store, tampering with connected AI agent workflows, or lateral movement.
AML.T0112

What systems are affected?

Package Ecosystem Vulnerable Range Patched
n8n npm — No patch
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
0.9%
chance of exploitation in 30 days
Higher than 58% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What should I do?

1 step
  1. Patch to n8n 1.123.67, 2.31.5, or 2.32.1 (or later) immediately — this is the only complete fix. Until patched: restrict the ability to create/execute workflows using the Git node to trusted administrators via n8n's RBAC/role settings; disable or remove the Git node from instances that don't need it; avoid pointing the Git node at repositories from untrusted or external contributors. Detection: monitor for unexpected git hook execution (post-checkout, pre-commit, post-merge, etc.) and for child processes spawned by the n8n service account that deviate from normal workflow execution patterns; review audit logs for recently created workflows referencing unfamiliar git repository URLs or local paths. If compromise is suspected, rotate all credentials stored in the n8n instance's credential vault and connected integrations.

What does CISA's SSVC say?

Decision Track
Exploitation none
Automatable No
Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.2.3 - AI system security controls
NIST AI RMF
MANAGE-2.3 - AI system risks are documented and mechanisms are in place to supersede, disengage, or deactivate systems that demonstrate performance or outcomes inconsistent with intended use
OWASP LLM Top 10
LLM08:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-72767?

CVE-2026-72767 is a remote code execution flaw in n8n's Git node: any authenticated user who can create and run workflows can stage a malicious local Git repository whose hooks fire under default git security settings, executing arbitrary commands as the n8n process user. This matters because n8n is widely deployed as an AI agent orchestration layer holding credentials, API keys, and integration secrets — a single crafted workflow can pivot from a low-privilege account into full host or cloud-tenant compromise, not just a contained script error. Exploitation pressure is currently moderate rather than acute: EPSS sits at 0.39% (top 68th percentile), the flaw is not in CISA KEV, no public exploit or Nuclei template exists, and CISA's SSVC decision is the lowest urgency tier, 'Track' — but authenticated RCE via a common developer primitive (git hooks) is trivial to weaponize once someone has workflow-creation rights, whether a malicious insider or a compromised low-privilege account. Upgrade immediately to n8n 1.123.67, 2.31.5, or 2.32.1; until patched, restrict who can create/execute workflows using the Git node and monitor for unexpected child processes or git hook execution under the n8n service account.

Is CVE-2026-72767 actively exploited?

No confirmed active exploitation of CVE-2026-72767 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-72767?

Patch to n8n 1.123.67, 2.31.5, or 2.32.1 (or later) immediately — this is the only complete fix. Until patched: restrict the ability to create/execute workflows using the Git node to trusted administrators via n8n's RBAC/role settings; disable or remove the Git node from instances that don't need it; avoid pointing the Git node at repositories from untrusted or external contributors. Detection: monitor for unexpected git hook execution (post-checkout, pre-commit, post-merge, etc.) and for child processes spawned by the n8n service account that deviate from normal workflow execution patterns; review audit logs for recently created workflows referencing unfamiliar git repository URLs or local paths. If compromise is suspected, rotate all credentials stored in the n8n instance's credential vault and connected integrations.

What systems are affected by CVE-2026-72767?

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

What is the CVSS score for CVE-2026-72767?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksAI workflow automation pipelinesAI agent orchestration

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0050 Command and Scripting Interpreter
AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2.3
NIST AI RMF: MANAGE-2.3
OWASP LLM Top 10: LLM08:2025

What are the technical details?

Original Advisory

n8n before 1.123.67, 2.x before 2.31.5, and 2.32.x before 2.32.1 contain a remote code execution vulnerability in the Git node. Authenticated users with rights to create and execute workflows can stage a crafted local repository that causes git to run hooks under default git security settings, executing arbitrary commands as the n8n process user. Both self-hosted and cloud instances are affected.

Exploitation Scenario

A low-privilege but authenticated n8n user (or an attacker who has compromised such an account) creates a new workflow using the Git node and points it at a repository they control, staged locally or accessible to the n8n host, with hook scripts (e.g., post-checkout or pre-commit) configured under default git security settings to run an attacker-supplied command. When the workflow executes and the Git node performs a clone, pull, or checkout against this repository, git invokes the malicious hook, running the attacker's command with the privileges of the n8n process. From there the attacker can dump credentials from n8n's secrets store, tamper with other AI agent workflows running on the same instance, or use the foothold to move laterally into connected systems and AI service integrations.

Weaknesses (CWE)

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.

Timeline

Published
August 11, 2026
Last Modified
September 9, 2026
First Seen
August 11, 2026

Related Vulnerabilities