CVE-2026-77084 in n8n
Summary
by MITRE • 08/20/2026
n8n before 1.123.69 (and 2.x before 2.33.4 / 2.34.1) contains a code execution vulnerability in the Git node. The Git node executed certain repository-local git configuration values without neutralizing them, so any subsequent Git node operation against a repository containing a malicious value would execute it as the n8n process user. This is not reachable through the Git node's own configuration controls and requires a separate file-write vulnerability elsewhere to plant the malicious value.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The identified security flaw resides within the git integration module of the n8n automation platform, specifically affecting versions prior to 1.123.69 for the v1 branch and before 2.33.4 or 2.34.1 for the v2 series. This vulnerability is classified as a code execution flaw that arises from improper neutralization of special elements during input processing, which aligns with CWE-78, commonly known as OS Command Injection. The core technical issue stems from how the git node handles repository-local configuration values stored in files such as .git/config or environment-specific settings within the working directory. When n8n interacts with a Git repository, it inherits certain configurations that can be manipulated by an attacker who has gained write access to those specific files.
The operational mechanism of this vulnerability relies on the fact that git commands executed by the application may interpret maliciously crafted configuration entries as executable scripts or external programs. For instance, if an attacker manages to inject a command into a local git config file through another vector, subsequent operations performed by n8n against that repository will trigger the execution of these injected values under the context of the user account running the n8n process. This effectively allows for remote code execution without direct interaction with the Git node's configuration interface, as the exploitation depends on the side-channel effect of reading tainted local configurations rather than a direct input field in the workflow editor.
The impact of this vulnerability is severe because it grants an attacker the ability to execute arbitrary commands on the host system where n8n is deployed. Since the code runs with the privileges of the n8n process, compromising this service can lead to full control over the underlying operating system, depending on the security context in which n8n operates. This could result in data exfiltration, lateral movement within a network, or complete compromise of infrastructure hosting automation workflows. The severity is further amplified by the fact that many organizations run such services with elevated privileges for ease of file access and integration capabilities.
Exploitation of this vulnerability requires an initial foothold to plant malicious values in repository-local configuration files. This means it is not a standalone remote code execution flaw accessible via standard API endpoints or workflow inputs alone but rather a secondary exploitation vector that depends on prior compromise, such as through CWE-436, which refers to interpretation ambiguity or insecure file handling elsewhere in the application stack. An attacker would need to leverage another vulnerability, such as an arbitrary file write issue, to inject the malicious git configuration before triggering a subsequent Git node operation within n8n. This dependency makes it less likely for automated scanning tools to detect but highly dangerous if combined with other weaknesses like CWE-732 or improper permission settings on shared directories.
To mitigate this risk, organizations must immediately upgrade their n8n instances to version 1.123.69 or later, or version 2.34.1 and above for the v2 branch, where these configuration values are properly sanitized before execution. Additionally, security teams should audit existing workflows that utilize Git nodes to ensure they do not interact with untrusted repositories unless strictly necessary. Implementing strict file system permissions is also critical; n8n processes should run under a dedicated service account with minimal privileges, adhering to the principle of least privilege defined in industry standards like CIS Benchmarks. This limits the potential damage even if an attacker manages to exploit this code execution path.
From a defensive monitoring perspective, security operations centers should look for anomalous process executions originating from n8n binaries or scripts that do not correspond to standard git commands. Tools aligned with MITRE ATT&CK techniques such as T1059 Command and Scripting Interpreter can help detect these lateral movements. Furthermore, integrating static application security testing into the development pipeline helps identify potential file write vulnerabilities elsewhere in custom integrations that could serve as the initial vector for this chain of exploitation. Regularly reviewing access controls on repository directories ensures that only authorized processes can modify configuration files, thereby closing the gap required to trigger this vulnerability.