n8n Webhook Vulnerability CVE-2026-21858: Content-Type Confusion to Full RCE

A single malformed Content-Type header. That's all it takes to go from zero access to full remote code execution on roughly 100,000 self-hosted n8n servers. CVE-2026-21858 — the n8n webhook vulnerability publicly disclosed on January 7, 2026 — carries a CVSS score of 10.0, the maximum possible severity rating. No authentication required. No user interaction needed. If your n8n instance has a Form Webhook node exposed to the internet, an attacker can read arbitrary files from your server, forge an admin session cookie, and execute any operating system command they want.

Cyera Research Labs discovered the vulnerability and named it "Ni8mare" — a fitting name for what is arguably the worst security flaw in n8n's history. Security researcher Dor Attias reported the flaw to n8n on November 9, 2025, and a patch was released in version 1.121.0 on November 18, 2025. The CVE was publicly assigned on January 6, 2026, with full details published the following day. The exploit chain is elegant in the worst possible way: it turns a content parsing oversight into complete server takeover.

How the n8n Webhook Vulnerability Exploit Chain Works

The attack exploits how n8n's Form Webhook node processes incoming HTTP requests. All webhook requests pass through a middleware function called parseRequestBody(), which inspects the Content-Type header to decide how to parse the request body. If the request is multipart/form-data, it uses a file upload parser (wrapping the Formidable library) that stores results in req.body.files. For all other content types, it uses a regular body parser that stores results in req.body.

The vulnerability exists because the Form Webhook's submission handler (formWebhook()) calls a file-handling function (prepareFormReturnItem() → copyBinaryFile()) that reads from req.body.files without first verifying that the Content-Type is multipart/form-data. This creates a Content-Type confusion attack where the attacker can override req.body.files through the regular body parser.

Step 1: Arbitrary File Read via Content-Type Confusion

The attacker sends an HTTP request to any active Form Webhook endpoint, but changes the Content-Type from multipart/form-data to application/json. This forces n8n to use the regular body parser instead of the file upload parser. The attacker crafts the JSON body to include a files object with a controlled filepath parameter — pointing to any file on disk instead of an uploaded temp file.

Since copyBinaryFile() copies the file at req.body.files[id].filepath without validating its origin, the attacker can read any file accessible to the n8n process. The first target is always the same:

# The attacker's first read target
/home/node/.n8n/database.sqlite

This is n8n's SQLite database. It contains everything: user accounts, hashed passwords, workflow definitions, credentials, and — critically — the admin user's session data. The attacker doesn't need to brute-force anything. The database hands them the admin password hash directly.

Step 2: Admin Cookie Forgery

Next, the attacker uses the same technique to read the n8n configuration file:

# Second file read
/home/node/.n8n/config

This file contains the encryption key and session secret that n8n uses to sign cookies and encrypt stored credentials. n8n stores its authentication session in a cookie called n8n-auth, which contains a signed payload with the user ID and a truncated SHA256 hash of the user's email and password, signed with the instance's encryption secret. With the admin's password hash from the database and the signing secret from the config, the attacker forges a valid admin session cookie. No password cracking required — they have everything they need to create a cookie the server will trust.

Step 3: Remote Code Execution via Execute Command Node

With admin access to the n8n dashboard, the attacker creates a new workflow containing an Execute Command node — n8n's built-in node that runs arbitrary shell commands on the host operating system. They trigger the workflow, and they now have a fully interactive shell on your server.

// What the attacker's workflow node looks like
{
  "nodes": [
    {
      "type": "n8n-nodes-base.executeCommand",
      "parameters": {
        "command": "cat /etc/passwd && whoami && id"
      }
    }
  ]
}

From here, it's standard post-exploitation: data exfiltration, lateral movement, persistence mechanisms, cryptocurrency miners — whatever the attacker wants. The n8n process typically runs as root in Docker containers, so there's no privilege escalation needed.

Why Content-Type Parsing Is Security-Critical

This vulnerability exists because of a fundamental truth that many developers overlook: request parsing is a security boundary. Every HTTP header your server interprets is an attack surface. Content-Type determines how your application reads the request body — and if that parsing logic has flaws, an attacker controls how your server interprets incoming data.

The n8n case isn't unique. Content-Type mishandling vulnerabilities have a long history — the infamous Equifax breach (CVE-2017-5638) also began with a malicious Content-Type header exploiting the Apache Struts Jakarta Multipart parser, though via expression injection rather than parsing confusion. The underlying pattern recurs: the application trusts the Content-Type header without sufficient validation, and an attacker exploits that trust to make the parser do something unintended.

Common Content-Type parsing mistakes that lead to vulnerabilities:

• Accepting any Content-Type on endpoints that expect a specific format. If your endpoint only handles JSON, reject anything that isn't application/json.
• Accessing file-handling data without verifying the Content-Type first. The CVE-2026-21858 root cause — req.body.files was read without checking that the request was actually multipart/form-data.
• Allowing attacker-controlled data to populate internal state. The regular body parser stored the JSON payload in req.body, which meant req.body.files was created from attacker input — a variable the file handler trusted implicitly.
• Falling back to a permissive parser when the Content-Type doesn't match. Strict rejection is safer than best-effort parsing.

The Bigger n8n Attack Surface Problem

CVE-2026-21858 didn't arrive alone. n8n has faced a wave of critical security disclosures between December 2025 and February 2026. CVE-2025-68613 (expression evaluation RCE, disclosed December 2025) and CVE-2025-68668 (Python Code node command execution) both preceded CVE-2026-21858. On the same day as the Ni8mare disclosure, CVE-2026-21877 (authenticated RCE via arbitrary file write, CVSS 10.0) was also published — and it can be chained with CVE-2026-21858 for an alternative exploitation path. Most recently, CVE-2026-27577 (sandbox escape RCE) and CVE-2026-27578 (auth bypass + stored XSS) were disclosed on February 25, 2026.

n8n has over 100 million Docker pulls. It's one of the most widely deployed workflow automation platforms in existence. The self-hosted model means patches don't auto-deploy — each operator has to manually upgrade. The fix for CVE-2026-21858 has been available since n8n v1.121.0 (released November 18, 2025), but security researchers estimate that tens of thousands of instances remain unpatched months later.

If you run n8n, check your version right now:

# Check your n8n version
n8n --version

# Or via Docker
docker exec your-n8n-container n8n --version

# If below 1.121.0, upgrade immediately
npm update -g n8n
# Or pull the latest Docker image
docker pull n8nio/n8n:latest

Test Your Webhook Endpoints for Content-Type Validation

Whether you use n8n or any other webhook handler, you should verify that your endpoints properly validate Content-Type headers. The core issue in CVE-2026-21858 is that a file-handling function ran without first checking the Content-Type — so the fundamental test is whether your endpoints reject unexpected content types before processing the body.

I built PinusX Webhook Inspector specifically for this kind of testing. You get a unique URL, send requests to it, and inspect every detail of what arrives — headers, body, content type, everything in real time. Here's how to use it to test for Content-Type confusion vulnerabilities:

1. Generate a test endpoint on PinusX Webhook Inspector.
2. Send a normal request with the expected Content-Type to confirm your baseline.
3. Send a request with a mismatched Content-Type — send application/json to an endpoint that expects multipart/form-data, with a JSON body that attempts to populate internal file-handling variables like files. Your handler should reject it before parsing.
4. Verify your handler returns 415 Unsupported Media Type (or 400 Bad Request) for unexpected Content-Types rather than attempting to parse them.

# Test: Send a JSON body to a form endpoint with file-override payload
curl -X POST https://your-webhook-endpoint.com/form \
  -H "Content-Type: application/json" \
  -d '{"files": {"file0": {"filepath": "/etc/passwd", "originalFilename": "test.txt"}}}'

# Expected: 400 Bad Request or 415 Unsupported Media Type
# If your server processes this and accepts the filepath, you have a problem

The key insight: your webhook handler should validate Content-Type before parsing the body. And any function that accesses file-handling data should verify that the request actually came through the file upload parser. This is exactly the check that was missing in n8n's formWebhook() function.

Hardening Your Webhook Handlers

Beyond Content-Type validation, every webhook endpoint should implement the security controls from our webhook security checklist: HMAC signature validation, timestamp verification, replay protection, and IP whitelisting where possible. You can also use PinusX's Hash Generator to verify HMAC calculations when debugging signature validation logic.

For n8n specifically:

• Upgrade to v1.121.0 or later. This is non-negotiable. Current latest versions are 1.123.10, 2.1.5, 2.2.4, and 2.3.0.
• Don't expose n8n directly to the internet. Put it behind a reverse proxy with authentication.
• Restrict network access to webhook endpoints. If only specific services send webhooks, whitelist their IPs at the firewall level.
• Disable the Execute Command node if you don't need it. n8n allows node type restrictions in the configuration.
• Monitor for unauthorized workflows. If an attacker gained access before you patched, check for workflows you didn't create.

Frequently Asked Questions