In early 2026, security researchers revealed a critical vulnerability in n8n, a popular automation platform, that allows attackers to completely take over unpatched servers — no credentials needed. Codenamed “Ni8mare” (CVE-2026–21858), this bug earned a CVSS 10.0 rating and put an estimated 100,000 self-hosted n8n instances at risk.

We’ll cover what n8n is, how this vulnerability works, its disclosure timeline, how to mitigate it, and lessons to prevent similar issues in the future.

What is n8n and How Is It Deployed?

n8n is an open-source workflow automation tool that lets users connect apps, APIs, and services via a visual editor. Think of it as a self-hosted alternative to Zapier, often used to automate tasks and orchestrate data flows (including AI/LLM integrations). It offers a friendly drag-and-drop interface with many pre-built integrations, enabling even non-developers to create complex automations. With over 100 million Docker Hub pulls and tens of thousands of weekly npm downloads, n8n has rapidly become the “central nervous system” of automation for many organizations.

Common Deployment: Companies typically deploy n8n as a server (often in a Docker container) on their own infrastructure. Users access it via a web UI to build and run workflows. Many instances are self-hosted on internal networks or cloud VMs; some are mistakenly exposed to the internet for convenience. This widespread self-hosting (as opposed to a fully managed cloud service) means security falls on the teams running n8n. Unfortunately, if misconfigured or left unpatched, an n8n instance can become a prime target — it often holds API keys, database credentials, and other sensitive connectors for all the integrated systems.

Understanding CVE-2026–21858: Content-Type Confusion to RCE

Overview: CVE-2026–21858 is an unauthenticated remote code execution vulnerability arising from a Content-Type confusion bug in n8n’s webhook handling logic. In simple terms, an attacker can craft a malicious HTTP request to an n8n webhook endpoint and trick the server into treating it as a file upload — even when it’s not — ultimately gaining the ability to read arbitrary files and execute code on the server. Let’s unpack how this works:

• Webhooks in n8n: Webhooks are triggers that start n8n workflows when they receive incoming HTTP requests (e.g. a form submission or a chat message). When a webhook call comes in, n8n uses a function parseRequestBody() to parse the request data, deciding how to handle it based on the Content-Type header. If the content type is multipart/form-data (typical for file uploads via forms), n8n invokes a file upload parser (parseFormData()) which uses the Node.js formidable library to safely handle file uploads (saving files to a temp directory with random paths). For any other content type (JSON, etc.), n8n uses a regular parser (parseBody()) that parses the request into a req.body object.
• The Bug — Content-Type Confusion: The vulnerability exists because one of n8n’s webhook flows does not verify that the request Content-Type is multipart/form-data before processing files. Specifically, the Form Webhook (formWebhook()) – which handles form submissions (e.g. when users upload files via an n8n form) – calls a file-handling function without enforcing the content type check. Under normal use, legitimate form submissions include the correct multipart/form-data header, so everything works as intended. But an attacker can send a form submission with an incorrect Content-Type (e.g. application/json). This confuses n8n’s middleware: instead of the file upload parser, it uses the regular parser and populates req.body from the JSON payload. Crucially, nothing prevents that JSON from containing a key named files – the same field the upload parser would have set.
• What This Means: By spoofing the Content-Type and carefully crafting the JSON body, an attacker can inject their own data into req.body.files. In the vulnerable flow, the code blindly trusts req.body.files and calls copyBinaryFile() on each file entry, assuming it was set by a legitimate upload parser. This is where the disaster happens: the attacker’s fake req.body.files can point to any file path on the server. As Cyera’s researcher Dor Attias explains, “since this function is called without verifying the content type is 'multipart/form-data,' we control the entire req.body.files object... That means we control the filepath parameter – so instead of copying an uploaded file, we can copy any local file from the system.” In effect, the attacker hijacks the workflow to read arbitrary files on the server by copying them into the workflow’s output.

Impact — From File Read to Full Takeover: Reading files on the server is bad enough — it can expose configuration secrets, credentials, or personal data. But the Ni8mare exploit doesn’t stop at file theft; it paves the way to complete system compromise:

• Arbitrary File Read: Using the trick above, the attacker can retrieve sensitive files from the n8n host. For example, the research team showed they could load the contents of critical files like /etc/passwd or n8n’s own database into the workflow output. Any file that the n8n process user has read access to is game.
• Leaking Secrets & Bypassing Auth: Among the files n8n stores locally are its SQLite database (which holds user accounts and password hashes) and its configuration file (which contains the instance’s encryption secret key). By abusing the vulnerability, an attacker can read the n8n database and config. In the Cyera demo, they used the malicious webhook to dump database.sqlite and the .n8n/config file. From these, they extracted the admin user’s ID, email, and hashed password, as well as the instance’s secret key. Armed with those details, the attacker can forge a valid admin session cookie (n8n’s n8n-auth JWT) and log in as the system administrator – effectively an authentication bypass.
• Remote Code Execution: Once the attacker has admin access to the n8n web interface, they essentially own the platform. At this point, achieving RCE is trivial: n8n allows administrators to create workflows with an “Execute Command” node (which runs arbitrary shell commands on the host). The attacker can create and run such a node to execute code of their choice on the server. In the end, they’ve gone from an external unauthenticated request to running OS commands on the n8n host — a worst-case scenario.

This one-two punch of file theft and code execution is why CVE-2026–21858 is so severe. As n8n’s advisory warns, a vulnerable workflow “could result in exposure of sensitive information… and may enable further compromise depending on workflow usage”. In practice, Ni8mare can expose secrets, allow admin impersonation, and open the door to full system takeover. And remember: because n8n often holds API keys and connects to many other systems, a compromise can cascade into a much larger breach. As the researchers put it, “a compromised n8n instance doesn’t just mean losing one system — it means handing attackers the keys to the kingdom”.

Timeline: Discovery, Disclosure, and Patching

Understanding the timeline helps illustrate how quickly this unfolded and when fixes became available:

• November 9, 2025: Dor Attias of Cyera discovered and reported the vulnerability to the n8n security team.
• November 10, 2025: n8n acknowledged the report the next day, indicating a prompt response.
• November 18, 2025: n8n released a patched version (v1.121.0) that fixes the issue. All n8n versions up to and including 1.65.0 are vulnerable; version 1.121.0 and later contain the fix. (The jump in version numbers was due to development branches — the key point is anything below 1.121.0 is unsafe.)
• December 29, 2025: The researchers, awaiting public disclosure, asked n8n for an update on publishing the details of the flaw.
• January 6, 2026: The CVE identifier CVE-2026–21858 was officially assigned to this issue. n8n also published a security advisory on GitHub detailing the impact and urging users to upgrade.
• January 7, 2026: Cyera publicly released their research blog post (“Ni8mare — Unauthenticated Remote Code Execution in n8n”) disclosing full technical details.

This coordinated disclosure gave users roughly two months from patch release to public disclosure. The good news is n8n’s team moved fast to fix the issue and pushed the patch well before details went public. The bad news: many self-hosted instances may not have upgraded in time, hence the urgent warnings in early 2026.

Mitigation and Remediation Guidance for n8n Users

If your team runs n8n, take action immediately:

1. Update n8n to the Fixed Version: Upgrade to n8n version 1.121.0 or later without delay. This is the only fully effective fix. The patched version corrects the improper request handling so that unauthenticated content-type spoofing can no longer override file paths. (As of the disclosure, newer releases like 1.123.x and 2.x also include the fix.)
2. Restrict Access to n8n: Until you can patch (and even after), do not expose n8n to the public internet unless absolutely necessary. Ensure n8n is behind a firewall or VPN. Lock down inbound access to only trusted networks or users. This reduces the chance of opportunistic attacks, since Ni8mare exploits can be executed remotely over the network.
3. Secure Webhooks and Forms: Harden the workflow endpoints themselves. Disable or restrict any unauthenticated webhooks or form triggers you have configured. If a workflow form must be public-facing, consider adding an authentication layer (e.g. requiring a token or login) before it reaches n8n. The n8n team specifically advises enabling authentication for all Form trigger nodes so that random attackers can’t hit them freely.
4. Temporary Workarounds: If for some reason you cannot upgrade promptly, one mitigation is to disable or throttle vulnerable endpoints. For example, you might remove any Form webhook nodes from active workflows, or use web server rules to reject requests that don’t match expected content types. These are not foolproof solutions, but can reduce risk while you prepare to update.

It’s worth noting that no official workaround existed aside from updating and limiting exposure. Ni8mare’s nature is such that if the server is reachable and running a vulnerable version with an exposed form webhook, it will be exploitable. So, the priority is to patch and tighten network access.

Strategic Takeaways for Preventing Similar Vulnerabilities

Stepping back, CVE-2026–21858 offers several broader lessons for security practitioners and software engineers. As we fortify our systems against this and future threats, keep these takeaways in mind:

• Treat Low-Auth Workflows as High-Risk: Any feature that accepts input without authentication (like a public webhook) should be a red flag. Build in strict validation and consider requiring auth even if it’s not “meant” to be sensitive. Here, an open form endpoint ended up as a gateway to our entire system — a reminder to lock down or closely monitor unauthenticated entry points.
• Validate Inputs Rigorously: The root cause was improper input handling — the code trusted Content-Type and req.body.files without verifying they matched an actual upload. Developers should enforce that inputs conform to expectations (e.g., if a file is expected, ensure the request is truly a file upload). Implement defense-in-depth in code: even if one check is missed, have another layer (like confirming req.body.files structure or rejecting unexpected fields). This is essentially CWE-20: Improper Input Validation – a common weakness we must guard against.
• Limit Exposure of Automation Platforms: Tools like n8n are incredibly powerful — they tie into many systems and often run with extensive privileges. That also makes them lucrative targets. As a strategy, minimize the attack surface: run them in internal networks, require VPN or SSO for access, and avoid leaving default ports open globally. Think of an automation server as you would a domain controller: central and must be protected accordingly.
• Keep Software Updated (and Monitor Advisories): This incident highlights the importance of timely patching. The fix was available in November, but many didn’t know until January. Maintain an inventory of your tools (like n8n) and subscribe to their security advisories or CVE feeds. Prompt updates for critical flaws can make the difference in averting a breach. If a quick patch isn’t possible, at least apply interim mitigations (as we outlined above) and plan upgrades as a priority.
• Routine Security Testing and Code Review: For engineering teams, incorporate tests for scenarios like this. Fuzz test your web endpoints with odd Content-Type headers, unexpected payload shapes, etc., to catch parsing logic bugs. In code reviews, watch out for assumptions (e.g. “this function only ever runs in context X”) and add explicit checks. If we had a unit test for formWebhook() ensuring it rejects non-multipart content, this bug might have been caught earlier in development.
• Defense in Depth: Finally, assume that bugs will happen, and build layers of defense. For instance, running n8n in a isolated container or with a minimal OS user can limit what an attacker can access if compromised. In Ni8mare’s case, the attacker read /home/node/.n8n files and /etc/passwd; a stricter containment strategy (filesystem permissions, AppArmor profiles, etc.) might have slowed them down. Also, storing fewer secrets on the automation server (or encrypting them) can reduce the “keys to the kingdom” problem. The goal is to ensure that one vulnerability doesn’t instantly yield total control.

Conclusion

Ni8mare (CVE-2026–21858) serves as a sobering reminder that even user-friendly automation tools need robust security controls. As your security lead, I urge our team to take this vulnerability seriously: patch our systems if we haven’t already, double-check that our n8n workflows aren’t exposed or misconfigured, and learn from this event. Unauthenticated RCEs are about as bad as it gets, but by applying the lessons above — from input validation to least exposure — we can reduce the risk of “nightmares” like this in the future. Let’s stay vigilant and make sure our automation heroes don’t become our weakest link.