CVE-2026-86081 in n8n
Summary
by MITRE • 09/09/2026
n8n is an open source workflow automation platform. Prior to 1.123.76, 2.37.7, and 2.38.2, the Git node clone operation matched an attacker-controlled destination path against the default N8N_BLOCK_FILE_PATTERNS regular expression. The pattern ^(./).git(/.)$ allowed catastrophic backtracking and ran synchronously in the main n8n process. An authenticated workflow editor could therefore freeze the instance with one workflow execution; the affected default is declared in packages/@n8n/config/src/configs/security.config.ts. This issue is fixed in versions 1.123.76, 2.37.7 and 2.38.2.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified within n8n, an open-source workflow automation platform, represents a critical security flaw rooted in improper input validation of file system paths during Git repository operations. Specifically, the issue resides in the clone operation executed by the Git node prior to versions 1.123.76, 2.37.7, and 2.38.2. The core technical deficiency involves the use of a regular expression designed to validate destination paths against a default security configuration known as N8N_BLOCK_FILE_PATTERNS. This pattern is defined in the source file packages/@n8n/config/src/configs/security.config.ts and aims to restrict access to sensitive directories, particularly those associated with Git metadata such as .git folders. However, the implementation of this validation mechanism contains a critical flaw that allows for catastrophic backtracking when processing attacker-controlled input.
Catastrophic backtracking is a well-documented vulnerability class where regular expressions exhibit exponential time complexity on certain inputs due to ambiguous quantifiers and nested groups. In this specific instance, the regex pattern ^(./).git(/.)$ was susceptible to such behavior. When an authenticated workflow editor provides a specially crafted destination path that triggers complex matching scenarios within the regular expression engine, the computational resources required to determine non-matching or partial matches escalate dramatically. Because this validation logic runs synchronously in the main n8n process thread rather than being offloaded to a worker pool or asynchronous context, the entire application becomes unresponsive during the evaluation of the malicious pattern. This synchronous execution model means that while one workflow is attempting to clone a repository with the crafted path, no other requests can be processed by the server, effectively causing a complete service outage for all users connected to the instance.
The operational impact of this vulnerability is severe, constituting a Denial of Service (DoS) condition accessible via authenticated access. An attacker who possesses valid credentials and has been granted workflow editing permissions within n8n can exploit this flaw by creating or modifying a workflow that includes a Git node configured with a malicious destination path. Upon execution of this workflow, the regular expression engine enters an infinite loop-like state due to catastrophic backtracking, freezing the main process indefinitely until it is manually restarted or times out under external load balancer constraints. This not only disrupts business continuity but also highlights significant risks in how automation platforms handle untrusted input during file system operations. The vulnerability aligns with CWE-400 (Uncontrolled Resource Consumption) and specifically relates to Regular Expression Denial of Service, often categorized under CWE-1335 or similar patterns depending on the specific regex engine behavior. In terms of offensive security frameworks, this exploitation technique maps to ATT&CK Tactic TA0002 Execution with potential persistence implications if the DoS is used as a distraction for other attacks, though primarily it serves as a resource exhaustion vector under TA0040 Impact.
Mitigation strategies focus on both immediate patching and long-term architectural improvements. The primary remediation step is to upgrade n8n to version 1.123.76, 2.37.7, or 2.38.2, where the regular expression has been corrected to prevent catastrophic backtracking while maintaining its security intent of blocking access to .git directories. For organizations unable to patch immediately due to operational constraints, implementing a Web Application Firewall (WAF) rule that detects and blocks HTTP requests containing patterns indicative of regex-based DoS attacks can provide temporary relief. Additionally, enforcing strict least-privilege principles for user accounts is crucial; ensuring that only trusted administrators have workflow editing rights reduces the attack surface available to potential insiders or compromised credentials. From a development perspective, future implementations should avoid using regular expressions for complex path validation where possible, opting instead for robust file system APIs and explicit allow-listing of permitted directories. Furthermore, moving such I/O-bound operations out of the main event loop into worker threads would prevent single malicious workflows from freezing the entire application instance, thereby enhancing overall resilience against resource exhaustion attacks.