CVE-2026-85168: n8n: Git node RCE via poisoned filter/merge config

HIGH
Published September 3, 2026
CISO Take

n8n's Git node only clears a fixed list of command-bearing git configuration keys before each operation, so a repository whose local config sets a content-filter or merge-driver command — paired with a matching .gitattributes pattern — can make git silently execute an attacker-chosen command during an ordinary Add, Commit, Checkout, or Pull, running as the n8n process user. n8n is one of the most widely deployed AI agent orchestration platforms, and the Git node is a natural building block for autonomous code-review, repo-sync, or CI-style agents, so any workflow that touches a shared, forked, or partially-trusted repository is exposed to this class of command injection (CWE-78). There is no published CVSS score, EPSS sits at a modest 0.37% (still top 70% percentile for exploit likelihood), it is not in CISA KEV, and no public PoC or Nuclei template exists yet — so treat this as real but not yet urgent. Patch to n8n 1.123.73, 2.35.4, or 2.36.2 immediately, and until then keep Git nodes off untrusted repositories and scope down the n8n process's filesystem and credential access. Given n8n's history of 211 other CVEs and an OpenSSF Scorecard of 6.7/10, this is one more argument for running n8n in an isolated, least-privilege environment whenever it touches external code.

Sources:NVDGitHub AdvisoryEPSSOpenSSFATLASvulncheck.com

What is the risk?

Exploitability hinges on an attacker being able to influence the local git configuration or .gitattributes of a repository that an n8n Git node subsequently operates on — for example a shared automation repo, a compromised or malicious fork, or a multi-tenant n8n deployment where one workflow's output can taint a repo directory used by another. No authentication or user-interaction data is published, but the mechanism itself (git invoking a locally-configured filter/merge-driver command) requires no unusual privileges beyond the ability to write repository configuration once, after which every subsequent routine git operation triggers execution. Low EPSS (0.37%) and absence from KEV/no public exploit keep near-term mass-exploitation risk low, but the impact ceiling — arbitrary command execution as the automation platform's process user — is high, especially in n8n instances that hold LLM API keys, cloud credentials, or other integration secrets. Overall: moderate risk, contained mainly to deployments where Git nodes process untrusted or shared repository content.

How does the attack unfold?

Staging
Attacker crafts or compromises a git repository, setting a content-filter or merge-driver command in its local .git/config and a matching file pattern in .gitattributes.
AML.T0099
Tool Invocation
An n8n workflow (often an AI agent automating code sync, review, or deployment) uses the Git node to Add, Commit, Checkout, or Pull against the poisoned repository.
AML.T0053
Exploitation
Because n8n's config reset misses the content-filter/merge-driver key families, git invokes the attacker's configured command, executing arbitrary code as the n8n process user.
AML.T0050
Impact
The attacker gains code execution inside the n8n runtime, exposing stored workflow credentials and integrations for theft, lateral movement, or persistence.
AML.T0055

What systems are affected?

PackageEcosystemVulnerable RangePatched
n8nnpm—No patch
209.2KOpenSSF 7.116 dependentsPushed yesterday44% patched~19d to patchFull package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.8%
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.73, 2.35.4, or 2.36.2 as soon as possible. Until patched: restrict Git nodes to repositories you control and trust, avoid cloning/pulling third-party or fork content through n8n workflows, and run n8n in an isolated container with minimal filesystem access and least-privilege credentials so a compromised process has limited blast radius. Audit any repositories used by n8n Git nodes for unexpected filter.<name>.smudge/clean or merge.<name>.driver entries in .git/config and unusual attribute mappings in .gitattributes. For detection, monitor for anomalous child processes spawned by the n8n process during git operations (EDR rule: shell/network processes forked from git invoked by node/n8n), and add file-integrity monitoring on .git/config for workflow-managed repos.

What does CISA's SSVC say?

DecisionTrack
Exploitationnone
AutomatableNo
Technical Impacttotal

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:

ISO 42001
A.6.2.6-AI system security
NIST AI RMF
GOVERN-6.1-Third-party risk policies
OWASP LLM Top 10
LLM08:2025-Excessive Agency

Frequently Asked Questions

What is CVE-2026-85168?

n8n's Git node only clears a fixed list of command-bearing git configuration keys before each operation, so a repository whose local config sets a content-filter or merge-driver command — paired with a matching .gitattributes pattern — can make git silently execute an attacker-chosen command during an ordinary Add, Commit, Checkout, or Pull, running as the n8n process user. n8n is one of the most widely deployed AI agent orchestration platforms, and the Git node is a natural building block for autonomous code-review, repo-sync, or CI-style agents, so any workflow that touches a shared, forked, or partially-trusted repository is exposed to this class of command injection (CWE-78). There is no published CVSS score, EPSS sits at a modest 0.37% (still top 70% percentile for exploit likelihood), it is not in CISA KEV, and no public PoC or Nuclei template exists yet — so treat this as real but not yet urgent. Patch to n8n 1.123.73, 2.35.4, or 2.36.2 immediately, and until then keep Git nodes off untrusted repositories and scope down the n8n process's filesystem and credential access. Given n8n's history of 211 other CVEs and an OpenSSF Scorecard of 6.7/10, this is one more argument for running n8n in an isolated, least-privilege environment whenever it touches external code.

Is CVE-2026-85168 actively exploited?

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

How to fix CVE-2026-85168?

Patch to n8n 1.123.73, 2.35.4, or 2.36.2 as soon as possible. Until patched: restrict Git nodes to repositories you control and trust, avoid cloning/pulling third-party or fork content through n8n workflows, and run n8n in an isolated container with minimal filesystem access and least-privilege credentials so a compromised process has limited blast radius. Audit any repositories used by n8n Git nodes for unexpected `filter.<name>.smudge/clean` or `merge.<name>.driver` entries in `.git/config` and unusual attribute mappings in `.gitattributes`. For detection, monitor for anomalous child processes spawned by the n8n process during git operations (EDR rule: shell/network processes forked from git invoked by node/n8n), and add file-integrity monitoring on `.git/config` for workflow-managed repos.

What systems are affected by CVE-2026-85168?

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

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration pipelinesCI/CD automation

MITRE ATLAS Techniques

AML.T0050Command and Scripting Interpreter
AML.T0053AI Agent Tool Invocation
AML.T0099AI Agent Tool Data Poisoning

Compliance Controls Affected

ISO 42001: A.6.2.6
NIST AI RMF: GOVERN-6.1
OWASP LLM Top 10: LLM08:2025

What are the technical details?

Original Advisory

n8n versions before 1.123.73, 2.35.4, and 2.36.2 contain a remote code execution vulnerability in the Git node. The node reset a fixed list of command-bearing configuration keys before each operation, but that list did not cover the content-filter and merge-driver key families. A repository with local configuration setting one of those keys together with a matching attribute pattern causes git to execute the configured command during an ordinary Add, Commit, Checkout, or Pull operation. The command runs as the n8n process user.

Exploitation Scenario

An attacker gains write access to (or forks and gets merged into) a git repository consumed by an n8n workflow — for instance a shared automation repo or an open-source project an AI coding agent syncs with. They add a `.gitattributes` rule mapping a common file pattern (e.g. `*.md`) to a custom filter or merge driver, and set that driver's command in the repository's local `.git/config` to a reverse shell or credential-exfiltration one-liner. Because n8n's Git node fails to reset the content-filter/merge-driver config families, the next time an agent workflow performs a routine Add, Commit, Checkout, or Pull against that repo — say, an autonomous agent syncing generated code — git silently executes the attacker's command as the n8n process user, handing the attacker code execution inside the automation platform along with access to whatever LLM, cloud, or SaaS credentials that n8n instance holds.

Weaknesses (CWE)

CWE-78 — Improper Neutralization of Special Elements used in an OS Command: 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 before 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
September 3, 2026
Last Modified
October 29, 2026
First Seen
September 3, 2026

Related Vulnerabilities