A maximum-severity (CVSS 10.0) unauthenticated remote code execution vulnerability in n8n — one of the most widely deployed open-source workflow automation platforms — has a public proof-of-concept and is being actively tracked. If you’re running an internet-accessible n8n instance, this warrants immediate action.

What Happened

Cyera Research Labs discovered and responsibly disclosed CVE-2026-21858, dubbed “Ni8mare,” a content-type confusion bug in n8n’s webhook and file-upload handling logic. The flaw allows a completely unauthenticated attacker to read arbitrary files from the underlying host, steal internal credentials, forge administrator sessions, and ultimately execute arbitrary code on the server.

The vulnerability was patched in n8n version 1.121.0. Public exploit code has been released on GitHub by security researcher Chocapikk, making this essentially a point-and-shoot exploit for any attacker who finds an exposed instance.

Technical Details

The root cause sits in how n8n handles webhook requests that involve file uploads. File-handling webhook handlers call req.body.files without first validating that the request’s Content-Type is multipart/form-data. When an attacker sends a request with Content-Type: application/json instead, n8n falls back to a standard JSON body parser. The attacker can then craft a JSON payload that manually constructs a files object containing arbitrary filesystem paths.

Because n8n trusts this attacker-controlled files object, it reads whatever path the attacker specifies directly from disk — no authentication check, no path sanitization. This creates an arbitrary file read primitive accessible from any public webhook endpoint.

From there, the attack chain escalates quickly:

  1. File read: Attacker retrieves n8n’s internal SQLite database (database.sqlite) or configuration files containing encrypted credentials and cryptographic key material.
  2. Key extraction: n8n encrypts stored credentials with a server-side encryption key. Reading the config file yields this key.
  3. Session forgery: With the encryption key, the attacker generates a valid JWT admin session token entirely offline — no brute force, no phishing.
  4. RCE: Authenticated as admin, the attacker creates a workflow with a native n8n Code node or Execute Command node to run arbitrary shell commands on the host.

The entire chain — from zero authentication to root shell — requires only a handful of HTTP requests and takes seconds against a vulnerable instance.

Affected versions: All n8n releases prior to 1.121.0 Fixed in: n8n 1.121.0 CVSS v3.1: 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

Impact Assessment

n8n has over 60,000 GitHub stars and is widely used by DevOps teams, startups, and enterprises for automating internal workflows — CI/CD triggers, API integrations, data pipelines, alerting, and more. Many self-hosted deployments expose webhook endpoints to the internet by design, since that’s core to how n8n integrates with external services (GitHub, Slack, Stripe, etc.).

The blast radius is severe: n8n instances typically hold credentials for every service they integrate with. A successful exploit against an n8n server doesn’t just compromise the automation platform — it hands the attacker a pre-loaded credential vault containing database passwords, API keys, OAuth tokens, and SSH keys for everything the organization has wired into its workflows.

Cloud-hosted n8n.cloud instances are not affected — this only impacts self-hosted deployments. However, self-hosted is extremely common in engineering-forward organizations, particularly those that want to avoid SaaS data exposure concerns.

With a CVSS 10.0 score, a working public PoC, and widespread deployment in organizations that specifically have high-value credentials in their workflows, this is a high-priority patch target.

What To Do Right Now

Patch first: Upgrade to n8n 1.121.0 or later. If you’re on Docker, pull the latest image and recreate your container. If installed via npm, run npm update -g n8n or update your package.json dependency.

If you can’t patch immediately:

  • Restrict public access to webhook and form endpoints at the network/reverse-proxy layer. Put n8n behind a VPN or require authentication at the ingress.
  • Audit your n8n logs for unexpected requests to webhook endpoints, particularly with Content-Type: application/json on routes that typically receive multipart form data.
  • Consider rotating all credentials stored in n8n’s encrypted database as a precaution — you have no way to confirm you weren’t already hit without log analysis.

Verify your version: Check n8n --version or the About page in the n8n UI. Anything below 1.121.0 is vulnerable.

Shodan/Censys exposure: Shodan searches for internet-exposed n8n instances show thousands of deployments. If yours is one of them, treat this as a fire drill.

References