CVE-2026-85168: n8n: Git node RCE via poisoned filter/merge config
HIGHn8n'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.
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?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | — | No patch |
Do you use n8n? You're affected.
How severe is it?
What should I do?
1 stepPatch 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/cleanormerge.<name>.driverentries in.git/configand 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/configfor workflow-managed repos.
What does CISA's SSVC say?
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:
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
MITRE ATLAS Techniques
AML.T0050Command and Scripting InterpreterAML.T0053AI Agent Tool InvocationAML.T0099AI Agent Tool Data PoisoningCompliance Controls Affected
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-78Improper Neutralization of Special Elements used in an OS CommandCWE-78Improper Neutralization of Special Elements used in an OS CommandCWE-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.
References
- github.com/n8n-io/n8n/security/advisories/GHSA-mwp5-2m32-r54hvendor-advisory
- vulncheck.com/advisories/n8n-before-1.123.73-remote-code-execution-via-git-nodethird-party-advisory
Timeline
Related Vulnerabilities
CVE-2026-3366310.0n8n: member role steals plaintext HTTP credentials
Same package: n8nCVE-2026-3366010.0TensorFlow: type confusion NPD in tensor conversion
Same package: n8nCVE-2026-2185810.0n8n: Input Validation flaw enables exploitation
Same package: n8nCVE-2026-275779.9n8n: Code Injection enables RCE
Same package: n8nCVE-2026-274949.9n8n: security flaw enables exploitation
Same package: n8n