CVE-2026-27498: 
NixOS vulnerability analysis and mitigation

CVE-2026-27498 is an authenticated remote code execution vulnerability in n8n, an open-source workflow automation platform, classified as "Arbitrary Command Execution via File Write and Git Operations." An authenticated user with workflow creation or modification permissions can chain the Read/Write Files from Disk node with git operations to execute arbitrary shell commands on the n8n host. The vulnerability affects all n8n versions prior to 1.123.8 and versions 2.0.0 through 2.1.x. It was disclosed on February 25, 2026, with patches released the same day. It carries a CVSS v3.1 score of 8.8 (High) and a CVSS v4.0 score of 9.0 (Critical) (GitHub Advisory).

The root cause is improper control of code generation (CWE-94), specifically the lack of access restrictions preventing the Read/Write Files from Disk node (n8n-nodes-base.readWriteFile) from writing to sensitive system paths such as .git configuration directories. An attacker crafts a workflow that first writes a malicious payload to a git configuration file (e.g., .git/config) using the file write node, then triggers a git operation node that causes git to execute the attacker-controlled configuration, resulting in arbitrary shell command execution on the n8n host. The fix introduced a regex-based file path blocking mechanism (N8N_BLOCK_FILE_PATTERNS) that by default blocks access to .git directories and their contents via the pattern ^(.*\/)*\.git(\/.*)*$, applied in the isFilePathBlocked function within file-system-helper-functions.ts (GitHub Advisory, Patch Commit 1, Patch Commit 2).

Successful exploitation grants an attacker full arbitrary shell command execution on the n8n host system, running as the n8n service account. This results in complete compromise of confidentiality (access to all data on the host), integrity (ability to modify or delete files and system configurations), and availability (potential service disruption). The attack requires only low-privilege authentication (workflow creation permissions), making it a significant risk in multi-user n8n deployments, and could enable lateral movement within the network from the compromised host (GitHub Advisory, Feedly).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability requires low-privilege authentication (workflow creation/editing rights), which lowers the barrier for exploitation in multi-tenant or shared n8n environments. The EPSS score is approximately 0.664%, indicating a relatively low but non-negligible probability of exploitation in the near term. No threat actor attribution has been reported, and the vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The vulnerability was detected by Qualys scanner (detection ID: 5008016).

1. Reconnaissance: Identify n8n instances running versions prior to 1.123.8 or between 2.0.0 and 2.1.x, accessible over the network. Obtain or create a low-privilege account with workflow creation or editing permissions.
2. Create a malicious workflow: Log in to the n8n instance and create a new workflow. Add a "Read/Write Files from Disk" node configured to write a malicious payload to a git configuration file path (e.g., .git/config within a directory accessible to the n8n process).
3. Inject malicious git configuration: Configure the file write node to write a git config entry that abuses git hooks or core.sshCommand/core.gitProxy settings to execute an arbitrary shell command (e.g., a reverse shell or command execution payload).
4. Trigger git operation: Chain a git operation node (e.g., a Git node performing a pull, fetch, or similar operation) in the same workflow that targets the repository whose .git/config was modified.
5. Achieve code execution: Execute the workflow. When the git operation runs, git reads the attacker-controlled configuration file and executes the embedded shell command as the n8n service account, achieving remote code execution on the host (GitHub Advisory, Patch Commit 1).

• Logs: n8n workflow execution logs showing workflows that combine ReadWriteFile node operations targeting .git directories followed by git operation nodes; unexpected shell command output in n8n execution logs.
• File System: Unexpected modifications to .git/config files on the n8n host, particularly entries referencing external commands or hooks; new or modified git hook scripts (e.g., .git/hooks/post-checkout, .git/hooks/pre-receive) with executable payloads.
• Process: Unusual child processes spawned by the n8n Node.js process (e.g., /bin/bash, curl, wget, nc, python) not associated with normal workflow execution; unexpected outbound network connections from the n8n host.
• Network: Outbound connections from the n8n server to unknown external IP addresses or domains, particularly on non-standard ports, following workflow execution events.

Upgrade to n8n version 1.123.8 (for the 1.x branch) or 2.2.0 (for the 2.x branch) or later, as these releases include the fix that blocks file access to .git directories via a regex pattern (n8n Release 1.123.8, n8n Release 2.2.0). If immediate upgrade is not possible, apply the following temporary mitigations:

• Restrict permissions: Limit workflow creation and editing permissions to fully trusted users only.
• Disable the vulnerable node: Add n8n-nodes-base.readWriteFile to the NODES_EXCLUDE environment variable to disable the Read/Write Files from Disk node.
• Configure file pattern blocking: Set the N8N_BLOCK_FILE_PATTERNS environment variable to block access to sensitive paths (default in patched versions: ^(.*\/)*\.git(\/.*)*$).

These workarounds do not fully remediate the risk and should only be used as short-term measures (GitHub Advisory).

n8n published an official security advisory and blog post on February 25, 2026, disclosing the vulnerability alongside the patches (n8n Blog, n8n Community). The vulnerability was reported by security researcher fatihhcelik and credited in the GitHub advisory. CyberKendra covered the disclosure, noting it as another critical RCE flaw affecting n8n (CyberKendra). Red Hat also tracked the CVE in their security database (Red Hat).