CVE-2026-33724: Improper SSH Host Key Verification in n8n Source Control

The n8n platform includes a Source Control feature designed to synchronize workflows with remote Git repositories. When administrators configure this feature to utilize SSH for authentication, n8n invokes the system's underlying Git client to perform pull, push, and clone operations. In versions prior to 2.5.0, this integration explicitly disables standard SSH host key verification protocols.

The core vulnerability, classified under CWE-639 (Authorization Bypass Through User-Controlled Key), stems from the application overriding secure default settings. Specifically, the application forces the SSH client to bypass the verification of the remote server's cryptographic identity. This architectural decision fundamentally breaks the Trust On First Use (TOFU) model inherent to the SSH protocol.

Consequently, the n8n application becomes vulnerable to Man-in-the-Middle (MitM) attacks. An adversary capable of intercepting network traffic between the n8n host and the remote Git provider can successfully masquerade as the legitimate Git server. This lack of cryptographic validation allows the attacker to compromise both the confidentiality and integrity of the synchronized workflows.

The root cause lies in the specific environment variables and arguments n8n supplies to the Git process during synchronization tasks. Git utilizes the system's SSH binary as the transport mechanism for the git:// and ssh:// protocols. Developers often use the GIT_SSH_COMMAND environment variable to pass custom authentication keys or options to this underlying SSH process.

In vulnerable versions, the n8n codebase constructs this environment variable with the explicit inclusion of the -o StrictHostKeyChecking=no flag. Under standard operation, the OpenSSH client requires the remote host's public key fingerprint to either exist in the known_hosts file or be verified interactively by the user (ask or yes modes). By setting the parameter to no, the SSH client automatically adds unknown host keys to the known hosts list and proceeds with the connection without validation.

This configuration instructs the n8n server to blindly trust any host key presented during the SSH handshake. If an attacker intercepts the TCP connection on port 22 and presents their own self-generated RSA or Ed25519 host key, the n8n SSH client accepts it immediately. The connection proceeds, establishing an encrypted tunnel with the adversary rather than the intended Git server.

The vulnerability manifests in how the Node.js application spawns child processes for Git operations. When the Source Control feature initiates a synchronization command, the application prepares the execution environment by defining SSH connection parameters. The vulnerable implementation overrides secure defaults to prevent automated processes from hanging on interactive prompts.

// Vulnerable Implementation Pattern (Pre-2.5.0)
const env = {
  ...process.env,
  // Flaw: Disables host key verification explicitly
  GIT_SSH_COMMAND: 'ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i /path/to/n8n/git_key'
};
 
child_process.spawn('git', ['pull', 'origin', 'main'], { env });

The patch applied in version 2.5.0 fundamentally alters this mechanism. Instead of disabling the verification, the application now enforces proper host key checking. The updated code requires administrators to supply the legitimate Git server's public keys, which n8n securely injects into a managed, temporary known_hosts file during the process execution.

// Patched Implementation Pattern (2.5.0+)
const env = {
  ...process.env,
  // Fix: Enforces strict checking against a populated known_hosts file
  GIT_SSH_COMMAND: `ssh -o StrictHostKeyChecking=yes -o UserKnownHostsFile=${managedKnownHostsPath} -i /path/to/n8n/git_key`
};
 
child_process.spawn('git', ['pull', 'origin', 'main'], { env });

Exploiting CVE-2026-33724 requires the attacker to hold a privileged network position. The adversary must be capable of intercepting and modifying traffic between the n8n instance and the configured Git server. This is typically achieved via ARP spoofing on a local network, DNS hijacking, or BGP routing manipulation on the broader internet.

Once positioned, the attacker sets up a malicious SSH server configured to accept connections and masquerade as the target Git repository. When the n8n instance initiates a scheduled or manual git pull operation, the attacker intercepts the request. The n8n application connects, receives the attacker's forged host key, and accepts it automatically due to the StrictHostKeyChecking=no configuration.

The attacker then serves a modified Git repository containing altered n8n workflows. Because n8n workflows are JSON definitions that can contain raw JavaScript, Python, or shell execution nodes, the attacker embeds malicious system commands within these workflows. When n8n synchronizes and executes the workflow, the injected code runs with the privileges of the n8n application, achieving Remote Code Execution.

The primary consequence of a successful attack is full system compromise via Remote Code Execution. By injecting malicious nodes into legitimate workflows, the attacker executes arbitrary commands within the context of the n8n process. This allows the adversary to read the local filesystem, pivot to internal networks, or deploy persistent backdoors.

Furthermore, the vulnerability carries a significant confidentiality impact. The Man-in-the-Middle position allows the attacker to intercept git push operations originating from the n8n instance. Workflows routinely store sensitive operational data, including API tokens, database connection strings, and proprietary business logic, all of which become directly accessible to the attacker.

The CVSS 4.0 base score of 6.3 reflects the High Attack Complexity (AC:H), as the necessity for a MitM network position limits the pool of potential attackers. However, the subsequent impacts on confidentiality, integrity, and availability are severe once this initial hurdle is overcome, making this a critical issue for deployments operating in untrusted network environments.

The definitive remediation for CVE-2026-33724 is upgrading the n8n deployment to version 2.5.0 or later. This release correctly enforces SSH host key verification by requiring valid remote host keys. Post-upgrade, administrators must verify that the correct host keys for their Git providers (e.g., GitHub, GitLab, Bitbucket) are properly configured within the n8n environment to re-establish the TOFU security model.

If immediate patching is unfeasible, administrators should implement strict compensating controls. The most effective workaround is disabling the Source Control feature entirely until the system can be upgraded. If Source Control must remain active, administrators must tightly control the network path between n8n and the Git server.

Network-level mitigations include establishing a dedicated, encrypted VPN tunnel or VPC peering connection directly to the Git infrastructure. This drastically reduces the probability of a successful MitM attack by eliminating untrusted routing hops. Additionally, administrators should implement rigorous monitoring of system logs for unexpected outbound SSH connections or unexpected workflow modifications.