n8n Webhook Vulnerability CVE-2026-21858: Content-Type Trick 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 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. The exploit chain is elegant in the worst possible way: it turns a content parsing oversight into complete server takeover in three HTTP requests.

How the n8n Webhook Vulnerability Exploit Chain Works

The attack exploits how n8n's Form Webhook node processes incoming HTTP requests. Normally, this endpoint expects multipart/form-data submissions from web forms. But the request parser doesn't properly validate the Content-Type header, and that single oversight creates a path traversal vulnerability that reads arbitrary files from the filesystem.

Here's the three-step chain, broken down:

Step 1: Arbitrary File Read via Content-Type Confusion

The attacker sends a crafted HTTP request to any active Form Webhook endpoint. By manipulating the Content-Type header's boundary parameter and injecting path traversal sequences, the multipart parser follows a filename reference to an arbitrary file on disk. The parser treats the file contents as form data and reflects them back in the response or makes them accessible through the workflow.

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 reads 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. 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 confusion vulnerabilities have appeared in Express.js body parsers, Apache Struts (the Equifax breach started this way), and dozens of other frameworks. The pattern is always the same: the parser 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.

• Parsing multipart boundaries without sanitizing path characters. The CVE-2026-21858 vector — boundary parameters containing ../ sequences should never reach the filesystem.

• Using the raw Content-Type header in file operations. Parameters extracted from headers must be treated as untrusted input, period.

• 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. Within 30 days of its disclosure, three additional n8n CVEs dropped: CVE-2026-27577, CVE-2026-27578, and CVE-2026-21877. All expand the webhook-related attack surface. And this follows two prior n8n CVEs from 2025 — CVE-2025-68668 and CVE-2025-68613.

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 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 easiest way to test this is to send crafted requests to your own endpoints and confirm they reject unexpected content types.

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:

4.

# Test: Send a request with a suspicious Content-Type boundary
curl -X POST https://your-webhook-endpoint.com/hook \
  -H "Content-Type: multipart/form-data; boundary=----WebKitFormBoundary../../etc/passwd" \
  -d 'test payload'

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

The key insight: your webhook handler should validate Content-Type before parsing the body. If the Content-Type doesn't exactly match what you expect, return an error and don't attempt to parse. This is basic input validation, but it's the exact check that was missing in n8n.

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.

• 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

What is CVE-2026-21858 and how severe is it?

CVE-2026-21858 is an unauthenticated remote code execution vulnerability in n8n's Form Webhook endpoint. It carries a CVSS score of 10.0 — the maximum possible severity. An attacker can exploit it without any credentials to read arbitrary files from the server, forge admin session cookies, and execute operating system commands. All n8n versions before 1.121.0 are affected.

How do I know if my n8n instance is vulnerable?

Run n8n --version or check your Docker image tag. Any version below 1.121.0 is vulnerable. If your n8n instance has any Form Webhook or Webhook node that is publicly reachable, it can be exploited without authentication. Upgrade immediately to the latest version and audit your workflows for any unauthorized Execute Command nodes.

Is n8n safe to self-host after this vulnerability?

n8n is safe to self-host if you keep it updated and follow security best practices. The patch in v1.121.0 fixes CVE-2026-21858. However, self-hosting any workflow automation tool means you're responsible for timely patching, network segmentation, and access control. Never expose n8n directly to the public internet without a reverse proxy and authentication layer in front of it.