What n8n Does

n8n is a low-code workflow automation platform. It provides a visual, node-based interface where users connect different services - Salesforce, Slack, OpenAI, internal APIs, databases - into automated workflows. A typical workflow might trigger on a GitHub webhook, pull data from an internal API, apply some conditional logic, then post a notification to Slack or open a Jira ticket.

The platform can be self-hosted (commonly via Docker or Kubernetes) or consumed as n8n's managed cloud offering. The open-source core means organizations can run it within their own infrastructure, which many do - more than 25,000 n8n instances were publicly exposed on the internet at the time this vulnerability was disclosed.

n8n instances typically hold API keys, database credentials, authentication tokens, and other secrets needed to connect services together. The workflows themselves often have broad permissions across an organization's infrastructure. Taking over an n8n instance doesn't just give an attacker access to n8n. It gives access to everything n8n is connected to.

The Ni8mare Vulnerability (CVE-2026-21858)

Cyera Research Labs discovered the vulnerability they named "Ni8mare" - a four-step attack chain that starts with a single malformed HTTP request and ends with arbitrary command execution on the host machine. No authentication required.

Step 1: Content-Type Confusion. n8n's webhook handlers process incoming HTTP requests differently depending on the Content-Type header. The parsing functions - parseRequestBody() and parseBody() - trust that header to determine how to handle the request body. An attacker sends a request with a multipart/form-data content type but a carefully crafted body that doesn't match what the parser expects. The result: the attacker gains control over the internal req.body.files structure, which n8n uses to track uploaded files.

Step 2: Arbitrary File Read. Once the attacker controls the file references in req.body.files, n8n can no longer distinguish between legitimate uploaded files and arbitrary file paths on the server's filesystem. The code path flows through prepareFormReturnItem and copyBinaryFile(), which read whatever file the attacker points to. The attacker reads n8n's internal SQLite database and its encryption key file directly from disk.

Step 3: Session Forgery. n8n's authentication relies on a signed session cookie called n8n-auth. The cookie contains a payload derived from user identifiers and a hash of credentials, signed using the local encryption secret. With both the user database and the signing secret already extracted in Step 2, the attacker forges a valid administrator session cookie and logs in without ever knowing a password.

Step 4: Remote Code Execution. n8n includes built-in workflow nodes designed for legitimate automation - including an "Execute Command" node that runs shell commands on the host. As an authenticated administrator, the attacker creates a new workflow that invokes this node and executes arbitrary commands. From a single HTTP request to full remote code execution, with no user interaction and no authentication barriers.

The vulnerability affects all n8n versions prior to 1.121.0 and was patched in that release.

Why a CVSS 10.0

The Common Vulnerability Scoring System (CVSS) rates vulnerabilities on a 0-to-10 scale. A score of 10.0 is the maximum - reserved for flaws that are remotely exploitable, require no authentication, need no user interaction, and result in full compromise of the affected system.

CVE-2026-21858 hits every one of those criteria. The attack starts from the network (any HTTP client can reach a webhook endpoint), requires no credentials, doesn't need anyone to click anything, and the outcome is unrestricted command execution on the host. The CWE classification is CWE-306: Missing Authentication for Critical Function.

The Other Flaws

Ni8mare didn't arrive in isolation. In the same January-February 2026 timeframe, multiple other critical vulnerabilities surfaced in n8n.

CVE-2026-1470, disclosed on January 27 by JFrog, is a separate RCE vulnerability in n8n's workflow Expression evaluation system. Expressions are user-supplied code snippets that run during workflow execution - meant for data transformation and conditional logic. JFrog found that these expressions were evaluated in a runtime context without sufficient isolation from the underlying Node.js process. An authenticated attacker could supply an expression that broke out of the sandbox and executed arbitrary JavaScript with the privileges of the n8n process. JFrog rated it CVSS 9.9 (one tick below maximum because it requires authentication). The affected versions spanned up to 1.123.17, plus versions 2.0.0 through 2.4.5 and 2.5.0.

Then, on February 5, 2026, six additional CVEs were disclosed in n8n in a single day. The batch covered remote code execution, command injection, arbitrary file access, and cross-site scripting. All six targeted authenticated functionality and all broke isolation boundaries between workflows, configuration, and the underlying host. Security researcher Amit Genkin characterized it plainly: "This is not random disclosure noise. It's a clear signal of systemic security weaknesses."

The Architecture Problem

n8n's security issues aren't random bugs in random features. They're a pattern of the same design problem repeating: the platform trusts user-controlled input in places where it shouldn't, and it grants workflow execution contexts more access to the host system than they need.

The webhook parser trusts Content-Type headers. The expression evaluator trusts user-supplied code. The file handling trusts attacker-controlled paths. In each case, a boundary that should separate untrusted input from sensitive operations either doesn't exist or is easy to bypass.

This matters more for n8n than for most software because of what the platform does. An automation hub sits at the intersection of everything it automates. An n8n instance connected to a company's Salesforce, Slack, AWS, database, and email systems holds credentials and API keys for all of them. Compromising n8n means compromising the entire connected toolchain.

For self-hosted instances, the risk compounds. Organizations running n8n on their own infrastructure control their own patching timeline. An instance exposed directly to the internet (as 25,000+ were at the time of disclosure) with no reverse proxy, no WAF, and no network segmentation is a single HTTP request away from full host compromise.

The Exposure Surface

The 25,000+ internet-exposed instances figure deserves context. n8n's webhook functionality is one of its primary features - workflows trigger on incoming HTTP requests. For webhooks to work, the n8n instance needs to accept traffic from the internet. Many organizations expose their entire n8n instance to receive webhook traffic, rather than placing webhook endpoints behind a reverse proxy or API gateway that limits which paths are accessible.

The Ni8mare attack specifically targets webhook endpoints. Every publicly exposed n8n instance running a version before 1.121.0 was a target. The attacker didn't need to find a specific page, guess a URL, or discover an undocumented endpoint. They just needed to find an n8n instance - a thing that Shodan, Censys, and other internet scanning services catalog automatically.

The Patch and the Problem

n8n released version 1.121.0 to address CVE-2026-21858, and subsequent patches for CVE-2026-1470 and the batch of six February CVEs. The individual fixes worked: Content-Type handling is now validated, expression evaluation is sandboxed more strictly, and file path validation is enforced.

But the volume and severity of what was found in the span of a few weeks suggests the fixes are catching symptoms, not causes. A codebase that yields a CVSS 10.0, a CVSS 9.9, and six more critical CVEs within a month has a trust-boundary design failure rather than a handful of isolated function bugs.

n8n had approximately 70,000 GitHub stars and was one of the most widely deployed open-source automation platforms at the time these vulnerabilities were disclosed. The gap between that adoption and the state of its security boundary enforcement is significant, and the rapid succession of critical disclosures in early 2026 made that gap public.