Security researcher Fatih Çelik has disclosed yet another critical remote code execution (RCE) vulnerability in n8n, the popular open-source workflow automation platform — and this one is deceptively elegant in how it works.
Tracked as CVE-2026-27498 and rated Critical (CVSS 4.0: 9/10), the flaw allows any authenticated user with workflow editing rights to fully compromise the server running n8n, with no special tools or exploits required.
This is the same researcher who previously uncovered CVE-2026-25053, a command injection bug in n8n's Git node that exposed the sshCommand parameter as an RCE vector. With CVE-2026-27498, Çelik essentially revisited that same vulnerability primitive — but this time, he weaponised n8n's own Read/Write Files from Disk node to deliver the payload, making it a pure node-chaining attack that bypasses any restriction on the Execute Command node.
How the Attack Works
The exploit chain is surprisingly clean. It requires just three standard n8n workflow nodes: a Git node, an HTTP Request node, and a Read/Write Files from Disk node.
First, an attacker clones an external Git repository onto the n8n host using the Git node, creating a .git directory on disk. Next, they use the HTTP Request node to pull a malicious Git config file from an attacker-controlled server — one that has the sshCommand field inside [core] overwritten with a shell command (e.g., sh /tmp/exploit.sh). A second HTTP request drops the actual exploit shell script into /tmp/ on the n8n machine. Then, the File Write node silently overwrites the legitimate .git/config inside the cloned repository with the poisoned version.
The final trigger? A simple git fetch via the Git node. The moment Git initiates an SSH connection, it reads the config and executes whatever command is sitting in sshCommand — in this case, a reverse shell connecting back to the attacker.
Three nodes. No special privileges beyond workflow creation. Full shell access on the n8n host.
Why This Matters
n8n sits at the centre of modern automation stacks. It holds API keys, OAuth tokens, database passwords, cloud credentials, and connections to internal systems — making a compromised instance far more damaging than a typical server breach. The platform serves over 3,000 enterprise customers with approximately 200,000 active users, many of whom self-host for data sovereignty reasons.
This vulnerability hits those deployments hardest. It also notably bypasses the common advice of disabling the Execute Command node, since it achieves code execution entirely through Git's own config behaviour — a reminder that locking the front door doesn't help if the chimney is open.
The n8n security team has patched the issue. Affected versions are all releases below 1.123.8 and 2.x versions below 2.2.0.
What You Should Do
Upgrade immediately to n8n 1.123.8 or 2.2.0 (or any later release).
- If upgrading isn't immediately possible, add
n8n-nodes-base.readWriteFileto theNODES_EXCLUDEenvironment variable to disable the File Write node. - Restrict workflow creation and editing permissions to fully trusted users only — this is the most impactful interim control.
- Run n8n in a container with a read-only root filesystem, mounting only the directories it genuinely needs write access to.
- Audit existing workflows for unexpected use of the Read/Write Files from Disk node in combination with Git operations.
n8n has been under significant security scrutiny in recent months, with over eight critical and high-severity CVEs disclosed since January 2026 alone. The consistent thread running through most of them: legitimate, powerful features that lack sufficient boundaries between user-controlled data and system-level operations. Organisations treating n8n as low-risk infrastructure should reconsider that assumption immediately.