n8n Git Node ReDoS via Default Blocked-File-Pattern

Technical Analysis

The Git node's clone operation validates the destination path synchronously against the default N8N_BLOCK_FILE_PATTERNS regex before allowing the clone to proceed. Because this pattern was poorly constructed, certain crafted path strings trigger exponential-time backtracking during regex evaluation. Since n8n evaluates this pattern in the main process rather than a sandboxed or worker thread, the resulting CPU exhaustion blocks the event loop and halts processing for all concurrently running workflows and users. An attacker only needs authenticated access to the instance (no special privileges) and the ability to configure a single Git node workflow to trigger the outage, making this a low-effort, high-impact availability attack against any agentic pipeline that relies on n8n as an orchestration or tool-execution layer.

Affected Systems

n8n

Detection Signatures

• Sustained 100% CPU utilization on the n8n main process correlated with Git node clone executions
• Workflow executions that hang indefinitely or time out specifically on Git node 'clone' operations
• Git node destination path parameters containing long repetitive or nested character sequences designed to induce backtracking
• Instance-wide unresponsiveness coinciding with a single workflow execution from a non-admin user
• Unusually long evaluation times for N8N_BLOCK_FILE_PATTERNS matches in debug/profiling logs

Remediation Steps

1. 1

   Upgrade n8n

   Update to n8n 1.123.76, 2.37.7, 2.38.2, or later, which replaces the vulnerable pattern with a linear-time equivalent.

2. 2

   Restrict instance access

   Limit n8n access to fully trusted, authenticated users only until the upgrade is applied.

3. 3

   Disable the Git node

   Add 'n8n-nodes-base.git' to the NODES_EXCLUDE environment variable to remove the vulnerable code path as a temporary mitigation.

4. 4

   Replace the blocked-file pattern

   Set N8N_BLOCK_FILE_PATTERNS to a backtracking-safe regex to reduce (but not eliminate) risk while upgrading.

5. 5

   Add resource isolation and timeouts

   Run workflow execution in isolated processes/containers with CPU and execution time limits so a single malicious workflow cannot degrade the whole instance.