CVE-2026-21858: How a Content-Type Trick Gives Attackers Full Control of Your n8n Server

In November 2025, researchers at Cyera Research Labs disclosed CVE-2026-21858, a critical unauthenticated remote code execution vulnerability in n8n, the popular open-source workflow automation platform. It carries a perfect CVSS score of 10.0, and the mechanics justify that rating: an attacker needs nothing more than a single HTTP request to begin a chain that ends with full control of the server.

n8n is used by an estimated 100,000 self-hosted instances globally, connecting databases, APIs, SaaS applications, and internal tools through automated workflows. Many of these instances process sensitive data: customer records, financial transactions, authentication tokens, and API credentials. A vulnerability that gives unauthenticated attackers remote code execution on these servers is about as bad as it gets.

What Happened

The vulnerability was discovered by Cyera Research Labs and reported to the n8n team on November 9, 2025. The n8n team responded quickly, releasing a patch in version 1.121.0 on November 18, 2025, just nine days after the initial report. The CVE was formally assigned on January 6, 2026, and public disclosure followed on January 7, 2026.

The severity is straightforward: any self-hosted n8n instance running a version prior to 1.121.0 that has at least one Form Webhook node exposed to the network is vulnerable to unauthenticated remote code execution. No credentials needed. No special configuration required. The attack chain takes an attacker from zero access to full system command execution in three stages.

How the Exploit Works

The exploit chain for CVE-2026-21858 is methodical and elegant in its simplicity. It abuses a single root cause -- Content-Type confusion in webhook request parsing -- and escalates through three distinct stages to achieve full remote code execution.

The root cause: Content-Type confusion

n8n's webhook handling pipeline includes a function called parseRequestBody() that determines how to parse incoming HTTP request bodies. This function inspects the Content-Type header to decide whether to treat the body as JSON, URL-encoded form data, or multipart form data (file uploads).

The Form Webhook node includes file-handling functions that call prepareFormReturnItem() to process uploaded files. Here is the critical flaw: these file-handling functions never verify that the Content-Type of the incoming request is actually multipart/form-data. They assume that if file data exists in req.body.files, it must have come from a legitimate multipart upload. But an attacker can send a request with a Content-Type: application/json header and include a crafted req.body.files object in the JSON body. The JSON parser populates req.body.files with attacker-controlled data, and the file-handling logic processes it without question.

This is Content-Type confusion: the parsing layer treats the request as JSON, but the processing layer treats the parsed result as if it came from a file upload. The attacker controls the file path references in the crafted JSON, and n8n reads whatever files those paths point to.

Stage 1: Arbitrary file read

The attacker sends a crafted JSON request to a Form Webhook endpoint. The JSON body includes a files object with entries whose filepath values point to files on the server's filesystem. When the Form Webhook node processes this request, it reads the specified files and includes their contents in the workflow's data pipeline.

The initial targets are predictable:

• /etc/passwd -- confirms the file read works and reveals system users
• /home/node/.n8n/database.sqlite -- the n8n SQLite database, which contains all user accounts, credentials, workflow definitions, and configuration data
• /home/node/.n8n/config -- the n8n configuration file, which contains the encryption secret used to protect stored credentials

A single request can exfiltrate the entire SQLite database. This database contains everything the attacker needs for the next stage.

Stage 2: Authentication bypass

With the SQLite database and the encryption secret in hand, the attacker extracts the admin user's credentials. n8n stores password hashes in the database, but the attacker does not need to crack them. Instead, they use the encryption secret extracted from the config file to forge a valid JWT authentication token.

n8n uses a cookie called n8n-auth to maintain authenticated sessions. The JWT is signed using the encryption secret. Since the attacker now has this secret, they can create a token for any user, including the admin account, and set it as their session cookie. The n8n server validates the token's signature, finds it legitimate, and grants full administrative access.

No password cracking. No brute forcing. The attacker simply signs their own admin ticket with the server's own key.

Stage 3: Remote code execution

With authenticated admin access, the attacker has full control over n8n's workflow engine. n8n includes a built-in node called "Execute Command" that runs arbitrary system commands on the host operating system. The attacker creates a new workflow (or modifies an existing one), adds an Execute Command node with their payload, triggers the workflow, and the command runs with the privileges of the n8n process.

From here, the attacker can do anything the n8n service account can do: read and write files, establish reverse shells, pivot to internal networks, access databases, exfiltrate data, or deploy persistence mechanisms.

Why This Matters

n8n is not a toy. It is production infrastructure. Organizations use it to automate business-critical processes: syncing CRM data with billing systems, processing customer support tickets, orchestrating CI/CD pipelines, managing cloud infrastructure, and connecting dozens of SaaS APIs through automated workflows.

The credentials stored in a typical n8n instance paint a picture of the damage an attacker can do:

• Database credentials. Connection strings for PostgreSQL, MySQL, MongoDB, and other databases that n8n workflows interact with
• API keys and OAuth tokens. Credentials for Slack, GitHub, AWS, Google Cloud, Stripe, Salesforce, HubSpot, and every other service connected through workflows
• SMTP credentials. Email server passwords that can be used for phishing or data exfiltration
• Internal service tokens. Authentication tokens for internal APIs, microservices, and infrastructure management tools
• Webhook secrets. Shared secrets and signing keys used to authenticate incoming webhook requests from partner systems

A compromised n8n instance is not just one server. It is a pivot point into every system that n8n connects to. The blast radius extends to every API, database, and service that has credentials stored in n8n's credential vault.

What n8n Got Wrong

The n8n team's response was fast. Nine days from report to patch is a commendable turnaround. But the vulnerability itself reveals patterns that are worth examining because they show up regularly in web application penetration tests.

Content-Type trust without verification

The core flaw is that the file-handling code trusted the structure of req.body without verifying that the request actually arrived as a multipart form upload. This is a violation of a basic input validation principle: never assume the format of data based on its location in a data structure. The presence of a files key in the request body does not mean files were actually uploaded. It means someone put a key called "files" in a JSON object.

This pattern appears across many frameworks and applications. Developers write code that processes parsed data structures and forget that an attacker can control not just the values but also the structure of the input. When one part of the system parses the request based on Content-Type and another part processes the result based on structural assumptions, Content-Type confusion vulnerabilities emerge.

Missing authentication boundary on sensitive code paths

The file read operation happens before any authentication check. The Form Webhook node is designed to be publicly accessible (it accepts form submissions from external users), but the file-handling logic that processes "uploaded files" should never read from arbitrary filesystem paths. The code path from "receive webhook request" to "read arbitrary file" had no authentication gate, no path validation, and no Content-Type verification standing in the way.

Sensitive data accessible to the application process

The n8n process can read its own SQLite database and config file, which contain everything needed to forge admin credentials. This is somewhat unavoidable for a self-contained application, but it means that any file read vulnerability immediately escalates to full authentication bypass. Defense-in-depth measures like separating the credential store from the application process, using a dedicated secrets manager, or encrypting the database with a key not stored on the same filesystem would have limited the impact of the file read.

How to Check If You Are Affected

Step 1: Identify your n8n version

Check your n8n version by one of these methods:

• Navigate to your n8n instance's settings page and check the version number
• Run n8n --version on the command line
• For Docker deployments, check the image tag: docker inspect n8n | grep Image
• Check the n8n API: GET /api/v1/version if accessible

If the version is below 1.121.0, you are running a vulnerable version.

Step 2: Check for exposed Form Webhook nodes

The vulnerability requires at least one Form Webhook node to be active and reachable over the network. Review your workflows for any Form Webhook or Webhook nodes that are exposed to the internet or to untrusted networks. If your n8n instance is internet-facing and running a vulnerable version, treat this as a high-priority patching emergency.

Step 3: Review logs for exploitation indicators

• Look for unusual POST requests to Form Webhook endpoints, especially those with Content-Type: application/json that include file path references in the body
• Check for unexpected workflow executions, particularly workflows containing Execute Command nodes
• Review access logs for new admin sessions or API token creation from unfamiliar IP addresses
• Monitor for outbound connections from the n8n server to unexpected destinations

Remediation Steps

Priority 1: Update n8n immediately

The fix is available in n8n version 1.121.0 and later. The patch adds Content-Type verification to the file-handling code path, ensuring that file processing only occurs when the request is genuinely a multipart form upload.

• Docker: Update your image tag to n8nio/n8n:1.121.0 or later and restart the container
• npm: Run npm update n8n -g to update to the latest version
• Self-hosted: Follow the n8n upgrade documentation for your deployment method

Priority 2: If you cannot update immediately

• Restrict network access. Place n8n behind a reverse proxy or firewall that limits access to Form Webhook endpoints. If the webhooks must be public, restrict access to known IP ranges where possible
• Disable Form Webhook nodes. Deactivate any workflows that use Form Webhook nodes until you can patch
• Monitor aggressively. Deploy network monitoring on n8n ports and watch for the exploitation patterns described above

Priority 3: Post-patch actions

• Rotate the n8n encryption key. The old key may have been exfiltrated. Generate a new N8N_ENCRYPTION_KEY and re-encrypt stored credentials
• Rotate all stored credentials. Every API key, database password, OAuth token, and service credential stored in n8n's credential vault should be rotated. If the SQLite database was exfiltrated, all of these are compromised
• Reset admin passwords. Change all n8n user passwords and invalidate existing sessions
• Audit workflow execution history. Review the execution log for any workflows that were run by unauthorized users, especially those containing Execute Command nodes
• Check for persistence. If you suspect compromise, look for unauthorized SSH keys, cron jobs, new user accounts, or modified system files on the n8n host

Lessons for Engineering Teams

CVE-2026-21858 is a textbook example of several vulnerability patterns that engineering teams should proactively address in their own applications.

Input validation must be Content-Type aware

When your application processes request bodies, the parsing layer and the processing layer must agree on what type of data they are handling. If parseRequestBody() uses the Content-Type header to decide how to parse, then every downstream function that processes the parsed result must also verify the Content-Type before making assumptions about the data's origin. This is especially critical for file upload handling: never trust that data in a "files" field actually came from a file upload without verifying the Content-Type was multipart/form-data.

Content-Type confusion is a pattern, not a one-off

This class of vulnerability appears wherever an application accepts multiple Content-Types on the same endpoint and processes them through different code paths that reconverge. If your API accepts both JSON and multipart form data, every processing function downstream of the parser needs to know which format actually arrived. Mismatches between parsing and processing create exploitable gaps.

We see this pattern regularly in web application penetration tests. Applications that accept JSON on endpoints designed for form data (or vice versa) often have inconsistent validation between the two parsing paths. Test every endpoint with unexpected Content-Types during your security reviews.

Credential isolation limits blast radius

When n8n's file read vulnerability exposed the SQLite database, the attacker got everything: user accounts, password hashes, the encryption key, and all stored credentials. If the credential store had been separated from the application (using a dedicated secrets manager like HashiCorp Vault, AWS Secrets Manager, or even a separate encrypted database with independent access controls), the file read vulnerability would not have escalated to a full authentication bypass.

Webhook endpoints need the same security rigor as APIs

Webhook endpoints are often treated as second-class citizens in application security. They are designed to receive external input, so developers sometimes skip input validation or authentication checks that they would apply to regular API endpoints. CVE-2026-21858 is a reminder that webhook handlers are API endpoints. They accept untrusted input, process it, and take actions based on it. They deserve the same validation, authentication, and authorization controls as any other endpoint in your application.

If your application exposes webhooks, include them in your webhook security review and ensure they are covered in your next penetration test.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.