n8n Merge Node Flaw Exposes 615K Instances to RCE

Another month, another critical n8n vulnerability. CVE-2026-33660 allows authenticated attackers to escape n8n's JavaScript sandbox and read arbitrary files from the host system—or worse—through the platform's Merge node when configured to use SQL mode.

The CVSS 9.4 score reflects the severity. Qualys researchers note that over 615,000 publicly accessible n8n instances exist, making this a substantial attack surface for organizations running self-hosted workflow automation.

This marks at least the fourth critical n8n vulnerability in the past three months. We covered the CVE-2026-25049 sandbox bypass in February, which itself bypassed fixes for December's CVE-2025-68613. The pattern suggests ongoing architectural challenges with n8n's sandboxing approach.

How the Sandbox Fails

n8n's Merge node includes a "Combine by SQL" mode that lets users join data from multiple workflow branches using SQL queries. Under the hood, this uses AlaSQL—a JavaScript SQL database designed to run in browsers and Node.js environments.

The problem: AlaSQL wasn't designed as a security boundary. When n8n passes user-controlled SQL to AlaSQL, certain statements can escape the intended sandbox. According to GitLab's advisory, the sandbox "fails to properly restrict certain SQL statements," allowing attackers to:

• Read local files from the n8n host
• Execute arbitrary commands
• Potentially pivot to other systems accessible from the workflow server

The vulnerability exists because AlaSQL supports SQL extensions beyond standard SELECT/INSERT/UPDATE operations. Some of these extensions interact with the underlying filesystem or execution environment in ways n8n's security model didn't anticipate.

Attack Requirements

Exploitation requires authenticated access to create or modify workflows. In enterprise deployments with strong access controls, this limits exposure to insider threats or compromised accounts. But many n8n installations run with weaker authentication:

• Self-hosted instances with default or weak credentials
• Multi-tenant deployments with open registration
• Development environments exposed to broader networks

The 615,000 publicly reachable instances almost certainly include configurations where workflow creation isn't adequately restricted.

Supply chain attacks present another vector. Malicious workflow templates shared through community forums or imported from untrusted sources could contain the exploit payload, triggering execution when an unsuspecting administrator imports and runs the workflow. We've seen similar supply chain techniques in npm and PyPI attacks targeting automation tooling.

Patched Versions

n8n addressed CVE-2026-33660 in three release branches:

Branch	Patched Version
2.14.x	2.14.1
2.13.x	2.13.3
1.x	1.123.27

Organizations should upgrade to one of these versions immediately.

Temporary Mitigations

If immediate patching isn't feasible, n8n recommends two workarounds:

1. Restrict workflow permissions — Limit workflow creation and editing to fully trusted users only. This reduces exposure to privilege escalation by lower-trust accounts.

2. Disable the Merge node — Add n8n-nodes-base.merge to the NODES_EXCLUDE environment variable. This prevents any workflows from using the vulnerable functionality.

Neither workaround fully addresses the risk. Disabling the Merge node breaks workflows that depend on SQL-based data combining, and permission restrictions don't help if a trusted account is compromised.

Detection Guidance

Qualys customers can identify vulnerable instances using QID 733901. For others, audit your deployment:

1. Check your n8n version against the patched releases
2. Review existing workflows for Merge nodes using "Combine by SQL" mode
3. Audit workflow modification logs for unexpected changes
4. Consider network-level restrictions on n8n administrative interfaces

Why This Keeps Happening

n8n's architecture allows users to execute code within workflows—that's the core value proposition. But sandboxing arbitrary code execution is notoriously difficult. Each new vulnerability suggests the boundaries between user-provided logic and system access aren't as strong as intended.

Organizations running self-hosted n8n should treat it as high-risk infrastructure requiring the same security attention as other internet-facing services. Default configurations, weak authentication, and delayed patching create exposure that attackers will eventually find. The 615,000 public instances represent a target-rich environment.