Postmortem Library

n8n: How the "Ni8mare" flaw left 100,000 servers open to total takeover

This article examines the January 2026 n8n security incident, where a critical input validation flaw allowed unauthenticated attackers to gain remote code execution on self-hosted instances. We explore how a Content-Type confusion bug in webhook request parsing led to full server takeover and what teams can learn from the response.

Company and product

n8n is a Berlin-based, low-code workflow automation platform that allows technical and non-technical users to connect various SaaS applications, APIs, and internal databases. Unlike many of its competitors, n8n offers a self-hosted version, making it a popular choice for enterprises that require high levels of data privacy and internal infrastructure integration.

The platform is designed to be highly extensible, supporting over 400 integrations and allowing for custom JavaScript or Python code execution. Because n8n instances often have broad access to internal systems, credentials, and sensitive tokens, they represent a high-value target for attackers looking to move laterally within a corporate network.

What happened

The vulnerability centered on a middleware function called parseRequestBody(). This function was responsible for parsing incoming HTTP requests for webhooks and form submission triggers. Under specific conditions, the middleware failed to properly validate the Content-Type header, leading to "Content-Type confusion."

An attacker could craft a malicious request that tricked the parser into overriding internal file references (req.body.files). This provided a primitive for an unauthenticated arbitrary file read. Attackers could use this to exfiltrate the local SQLite database and the config file, which contained the encryption secret used for signing session cookies.

Once the encryption secret was obtained, the attacker could forge a valid administrator session cookie, effectively bypassing all authentication. From there, they could create a new workflow containing an "Execute Command" node to run arbitrary OS commands on the underlying server. Given that an estimated 100,000 servers were exposed globally, the potential for widespread exploitation was significant.

Timeline

  • November 9, 2025: Vulnerability (CVE-2026-21858) discovered and responsibly disclosed to n8n by Dor Attias of Cyera Research Labs.
  • November 18, 2025: n8n releases version 1.121.0 containing the fix for the unauthenticated RCE. Cloud instances are automatically patched.
  • January 8, 2026: n8n publishes a formal security advisory and blog post to alert self-hosted users who had not yet upgraded.

Time to Detect (TTD): N/A (Discovered via security research).

Time to Resolve (TTR): 9 days (From initial report to the release of a stable patch).

Who was affected?

The vulnerability primarily affected self-hosted users running n8n versions between 1.65.0 and 1.120.4. Specifically, instances were vulnerable if they had an active workflow using both a Form Submission trigger and a Form Ending node returning a binary file. n8n Cloud customers were not affected, as the platform team patched managed instances immediately after the fix was developed in November 2025.

How did n8n respond?

n8n followed a responsible disclosure process. Upon receiving the report in November, they prioritized a fix and quietly released it as version 1.121.0. They purposefully delayed the public advisory until January 2026 to provide a "buffer period," allowing the majority of self-hosted users to upgrade before the technical details and proof-of-concept (PoC) were made public.

Additionally, n8n provided a workflow template that users could run on their own instances to scan for potentially vulnerable configurations, helping teams assess their risk without needing to manually audit hundreds of workflows.

How did n8n communicate?

Communication was transparent but controlled. The January 8 advisory clearly outlined the technical nature of the flaw, the impacted versions, and the necessary remediation steps. By coordinating with the researchers at Cyera, n8n ensured that the full "Ni8mare" technical breakdown was only released after the patch had been available for several weeks. This reduced the risk of "Day Zero" mass exploitation by script kiddies.

Key learnings for other teams

  • Strict input validation: Never trust the Content-Type header implicitly. Ensure that your request parsers enforce expected formats and do not allow user-controlled headers to override internal state variables.
  • Defense in depth: n8n's "Execute Command" node is powerful but dangerous. Organizations should use n8n’s built-in environment variables to disable or restrict high-risk nodes (like the Execute Command or FS nodes) unless they are strictly necessary.
  • Session security: Avoid relying solely on a single static encryption secret stored in a configuration file for session signing. Consider rotating secrets or using more robust KMS-backed session management.
  • Automate security scans: For platforms that allow user-generated logic (like workflows), provide automated tools or "health check" workflows to help users identify insecure patterns.

Quick Summary

n8n addressed a critical unauthenticated RCE (CVE-2026-21858) caused by improper input validation in its webhook middleware. The "Ni8mare" flaw allowed attackers to read server files, forge admin sessions, and execute code. Self-hosted users are urged to update to version 1.121.0 or later immediately.

How ilert can help

When critical vulnerabilities like "Ni8mare" are disclosed, speed is of the essence. ilert helps teams manage the resulting "fire drill" by:

  • Alerting on security signals: Integrating with Intrusion Detection Systems (IDS) or vulnerability scanners to alert your security team the moment an exploit attempt is detected.
  • On-Call transparency: Ensuring that the right security engineers are paged immediately when a high-severity CVSS 10.0 advisory is released, keeping your infrastructure secure 24/7.
  • Secure incident war rooms: During a sensitive security incident, you need to keep technical discussions and "day zero" details private. With ilert, you can create private Slack channels directly from the incident. This ensures that only authorized personnel have access to sensitive troubleshooting logs or vulnerability details, keeping the information closed and secure.
  • AI-Assisted stakeholder communication: Maintaining trust during a global security advisory is all about transparency. ilert’s AI-assisted incident communications can instantly draft professional, technical, and accurate updates for your status pages. It ensures that your users and internal stakeholders are kept informed with the right level of detail while your engineers stay focused on the fix.

Find more Postmortems:
Ready to elevate your incident management?
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Our Cookie Policy
We use cookies to improve your experience, analyze site traffic and for marketing. Learn more in our Privacy Policy.
Open Preferences
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.