CVE-2026-85168 in n8n
Summary
by MITRE • 09/03/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in n8n versions prior to 1.123.73, 2.35.4, and 2.36.2 represents a critical remote code execution flaw located within the Git integration node. This security defect stems from an incomplete input validation mechanism when handling repository configurations during standard version control operations such as adding files, committing changes, checking out branches, or pulling updates. The core issue arises because the n8n application attempts to sanitize command-bearing configuration keys by resetting a fixed list of known dangerous parameters before executing git commands. However, this sanitization logic is flawed due to its static nature and failure to account for all potential vectors through which arbitrary code execution can be triggered via Git's internal mechanisms.
Specifically, the vulnerability exploits two specific families of Git configuration settings that were omitted from the whitelist used by n8n: content-filter and merge-driver keys. These configuration options allow users to define custom scripts or commands that Git invokes during specific operations like diff generation or conflict resolution. When a malicious actor controls the repository being accessed through the n8n workflow, they can configure these attributes within the local git config file of that repository. Because n8n does not reset or validate these particular keys before passing them to the underlying git binary, any command specified in these configurations is executed directly by the operating system shell without restriction.
The operational impact of this vulnerability is severe, as it allows for arbitrary remote code execution on the host machine running the n8n instance. Since the git commands are executed with the same privileges as the n8n process user, an attacker can achieve full control over the application environment if that user has elevated permissions or access to sensitive data and internal services. This effectively bypasses any intended isolation boundaries within the workflow automation platform, enabling attackers to exfiltrate credentials, install backdoors, pivot into other network segments, or disrupt service availability by manipulating system processes.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection), as it involves the injection and subsequent execution of malicious code through improperly sanitized configuration inputs. In terms of adversary behavior mapping to MITRE ATT&CK techniques, this scenario corresponds to T1059 Command and Scripting Interpreter, where an attacker uses system utilities like git to execute commands, and potentially T1204 User Execution if the initial vector involves tricking a user into triggering a workflow that pulls from a malicious repository. The attack chain relies on the trust relationship between n8n and external repositories, highlighting risks associated with integrating untrusted or compromised source code management systems into automation pipelines.
Mitigation strategies must prioritize immediate upgrading to patched versions of n8n where this whitelist has been expanded to include content-filter and merge-driver keys along with any other potential command injection vectors. In environments where an upgrade is not immediately feasible, administrators should enforce strict allow-listing of trusted repositories within the Git node configuration to prevent connections to unverified or potentially malicious sources. Additionally, running n8n processes under restricted user accounts with minimal privileges can limit the blast radius of a successful exploitation attempt by preventing access to sensitive system resources and reducing the impact of arbitrary command execution. Regular auditing of workflow configurations and repository permissions further strengthens the security posture against such supply chain-based attacks.