Ni8mare (CVE-2026-21858) is a critical unauthenticated remote code execution (RCE) vulnerability in the n8n workflow automation platform that abuses a content‑type confusion bug in webhook and form handling to escalate from arbitrary file access to full instance takeover. It combines weak input validation, overly trusting workflow logic, and powerful automation capabilities into a single exploit chain that can compromise not just n8n, but every system it orchestrates.

n8n is widely used as a low-code automation hub that glues together APIs, databases, internal services, and third‑party SaaS platforms. That central position makes it both business‑critical and highly privileged: instances often store API keys, OAuth tokens, database credentials, and can execute system‑level commands as part of normal workflows. Ni8mare weaponizes that centrality, turning a single exposed webhook endpoint into a pivot point for deep infrastructure compromise.

At its core, Ni8mare (CVE-2026-21858, CVSS 10.0) affects n8n versions 1.65.0 up to but not including 1.121.0, and is fully remediated in 1.121.0 and later. The vulnerability was disclosed publicly in early January 2026 and is now well understood, with multiple security researchers publishing detailed analyses and practical exploit guidance. Given its unauthenticated nature and the prevalence of internet-exposed n8n instances, the window between disclosure and exploitation is especially dangerous.

How Ni8mare Works: From Webhook to RCE

Ni8mare’s power lies in how it collapses multiple security boundaries at once. It begins with a deceptively simple flaw: content-type confusion in webhook/form request handling.

Under normal conditions, when a request is sent to a form or file-upload workflow:

– If the request uses `multipart/form-data`, n8n invokes a multipart parser.
– Uploaded files are parsed and mapped into a trusted structure, typically exposed to the workflow as `req.body.files` or equivalent metadata.
– Workflow nodes downstream rely on that structure to safely access user-uploaded content.

Ni8mare breaks this model. Certain webhook and form handlers in vulnerable n8n versions read `req.body.files` without validating the request’s `Content-Type` header. That means:

– An attacker can send a request labeled as `application/json`.
– Inside the JSON body, they can inject a crafted `files` object.
– Because the handler does not enforce that files only come from multipart parsing, it treats this attacker-controlled `files` structure as if it represented legitimate uploaded files.

This content-type confusion effectively lets the attacker forge file metadata and file paths. Instead of representing a user upload, each “file” entry can be made to point directly to arbitrary paths on the n8n host filesystem. Any workflow node that assumes `files` is trustworthy can now be tricked into reading or acting on arbitrary local files.

Security advisories describe this initial impact as unauthenticated file access via improper webhook request handling. In practice, that is the first step in a three‑stage exploit chain:

1. Arbitrary File Read
Once `req.body.files` becomes attacker‑controlled, workflows that process uploads or file paths may read from arbitrary files on disk.
Attackers can target:
– Configuration files
– Internal n8n databases
– Secrets used for session signing or encryption
– Any other readable file accessible to the n8n process

This turns the vulnerable instance into a file exfiltration oracle: by carefully crafting the `files` object and observing workflow outputs, an attacker can extract sensitive data that was never meant to be exposed.

2. Admin Session Forgery
Among the files accessible via this mechanism are those containing authentication and session management secrets. With these values, an attacker can:
– Forge valid administrator authentication cookies.
– Bypass login entirely.
– Gain full access to the n8n management interface without any prior credentials.

At this point, the attack has silently shifted from a single HTTP request to full administrative control of the platform. The original unauthenticated flaw essentially becomes a stepping stone to a fully authenticated, highly privileged session.

3. Remote Code Execution on the Host
With administrative access, an attacker can leverage n8n’s most powerful capabilities:
– Create or modify workflows.
– Introduce nodes that invoke system‑level commands.
– Use existing integrations (shell, code nodes, external tools) that already execute code or scripts as part of normal automation.

This turns the platform’s flexibility against itself. Ordinary automation behavior becomes the RCE primitive: by triggering a malicious workflow, the attacker can run arbitrary commands on the underlying host with the same privileges as the n8n service.

At that point, the n8n instance is effectively owned, and the host OS, connected networks, and integrated systems are all within reach.

The attack chain completes without user interaction and without ever passing through normal authentication boundaries. A single exposed workflow endpoint, if built in a vulnerable pattern, is enough.

Affected Versions, Scope, and Exposure

Official advisories and scanners agree on the impacted range:

– Affected: n8n versions 1.65.0 up to but not including 1.121.0.
– Fixed: 1.121.0 and later, where the underlying improper webhook request handling is corrected.

The vulnerable components are:

– Webhook handlers
– Form-based workflow logic
– File upload and parsing paths used by self‑hosted n8n deployments.

In practice, two factors define real-world exposure:

– Internet-facing n8n instances
Security research notes that a large number of n8n servers are reachable from the public internet. Public forms, webhooks, and automation endpoints are often deliberately unauthenticated to integrate with external systems, making them ideal targets for Ni8mare.

– Presence of specific workflow patterns
A detailed exploitation analysis emphasizes that not every vulnerable version is equally exploitable. For Ni8mare to be abused in the wild, an environment typically needs:
– At least one publicly accessible form component workflow reachable without authentication.
– A mechanism for the attacker to retrieve or observe the contents of files referenced through the forged `files` object—for example:
– A workflow that exposes file data via responses or logs.
– An AI chatbot node with read access to files.
– Execution logs or download links visible to users that the attacker can access in some way.

These preconditions mean that while the vulnerability is structurally critical, practical exploitation depends on how each organization has designed their workflows. Research suggests that default deployments may not expose all the necessary pieces, but customized automation setups frequently do.

Why Ni8mare Is So Dangerous

Ni8mare’s severity is not just a function of its CVSS score; it derives from how it interacts with the trust model of automation platforms:

– Centralized credentials and access
n8n often functions as a central broker, holding the keys to APIs, databases, cloud providers, message queues, and more. Compromise of the automation engine equates to compromise of everything it can reach.

– Implicit trust in internal data flows
Workflow designers typically assume that internal fields like `files` or form outputs are validated and safe. Ni8mare exploits that assumption of trust by allowing untrusted attackers to populate these structures without passing through the expected parsing or validation layers.

– Multiplicative impact across workflows
A single vulnerable form or webhook can provide access to:
– Shared credential stores
– Global configuration
– Reusable nodes and templates used across many automations

The blast radius is rarely confined to one workflow; it often spans the entire n8n project or instance.

– Ease of exploitation once prerequisites are met
Once an attacker identifies a suitable endpoint and a way to view file contents, the exploit chain—file read, secret extraction, admin session forging, RCE—is scriptable and repeatable. Public proofs of concept and research have already lowered the barrier to entry for attackers.

Ni8mare in Context: A Cluster of Critical n8n Issues

Ni8mare is the only vulnerability in its disclosure cluster that enables unauthenticated exploitation, but it is part of a broader set of high‑severity RCE issues in n8n affecting authenticated users. These include:

– CVE-2026-21877
A flaw in file upload handling that allows authenticated users to upload dangerous file types, enabling code execution via the n8n service.
– Severity: 10.0
– Patched in: 1.121.3

– N8scape (CVE-2025-68668)
A sandbox escape in the Python Code Node, allowing a user with workflow editing permissions to break out of the Pyodide-based sandbox and run arbitrary system commands on the host.
– Severity: 9.9
– Patched in: 2.0.0

– CVE-2025-68613
An issue in dynamically managed code resources that can be abused under specific conditions by authenticated users to achieve RCE within the n8n environment.

Together, these vulnerabilities highlight a systemic risk profile for low‑code automation engines: when code execution, file access, and powerful integrations are normal features, any input validation flaw or sandbox escape can rapidly escalate into full host compromise.

Stakeholders and Real-World Impact

Ni8mare affects a wide spectrum of stakeholders:

– Self-hosted n8n operators (DevOps, SRE, platform teams)
They face the most immediate operational risk. A successful Ni8mare exploitation can:
– Take over the n8n instance and its underlying host.
– Expose secrets used across CI/CD, infrastructure as code, and internal APIs.
– Be used as a pivot point into internal networks or cloud environments.

– Security teams and incident responders
Need to:
– Rapidly identify all affected n8n deployments.
– Determine whether public forms or webhooks exist on vulnerable versions.
– Investigate for signs of compromise, such as unexpected workflows, anomalous admin sessions, or unusual command execution on n8n hosts.

– Application and automation engineers
Must reassess assumptions about:
– How they handle webhooks, forms, and file uploads.
– Whether internal fields can be trusted.
– How much power is exposed to low‑privilege workflows.

– Vendors and integrators
Organizations embedding n8n into their own products or delivering it as part of managed services must:
– Patch or upgrade customer environments.
– Review default templates to avoid vulnerable patterns.
– Communicate risk and remediation steps clearly to downstream customers.

In the worst case, Ni8mare can lead to full infrastructure compromise: attackers who gain control of n8n may alter production workflows, siphon data from CRMs or ERPs, manipulate billing systems, or interfere with operational automations. Because automation systems often run unattended and are implicitly trusted, such changes can go unnoticed longer than typical application breaches.

Mitigation, Patching, and Hardening

Security guidance around Ni8mare is unequivocal: upgrading is mandatory.

– Upgrade to at least n8n 1.121.0
The core Ni8mare vulnerability—improper webhook request handling leading to arbitrary file access—is fixed in 1.121.0.

– Apply subsequent security releases
To address related authenticated RCE issues (such as CVE-2026-21877) and further hardening:
– Upgrade beyond 1.121.3 and toward 2.x where sandbox and code‑related fixes (e.g., N8scape) are present.

– Do not rely on workarounds alone
Researchers emphasize that no robust, general-purpose official workaround exists that fully mitigates Ni8mare without upgrading, especially for internet‑exposed instances. While restricting access to webhooks, using WAF rules, or disabling certain endpoints can reduce risk, these measures are brittle and error-prone.

In addition to patching, organizations should adopt structural defenses:

– Reduce exposure of public forms and webhooks
– Prefer authenticated endpoints where possible.
– Limit public forms to the minimal data required.
– Avoid workflows that allow public input to influence file paths or access control.

– Segment and constrain n8n’s runtime environment
– Run n8n with least privilege: minimal OS permissions, no unnecessary root access.
– Use containerization and network segmentation to limit lateral movement if compromise occurs.
– Isolate access to particularly sensitive systems behind additional authentication layers, even if n8n is compromised.

– Harden workflow design patterns
– Treat all inbound fields, including `files`, as untrusted unless validated.
– Avoid designs where public input directly controls which files are read or which commands are executed.
– Introduce explicit validation nodes or logic before acting on external data.

– Monitor for signs of exploitation
Because Ni8mare can yield full admin access, defenders should:
– Review audit logs for new or modified workflows that were not change-controlled.
– Look for suspicious execution patterns, especially workflows that invoke shell commands or unusual integrations.
– Monitor host-level logs for unexpected processes spawned by the n8n service.

Lessons for Automation Security

Ni8mare is a textbook example of how small validation errors in complex automation systems can produce outsized security failures:

– Flexible parsing and polymorphic inputs (JSON vs multipart) expand developer convenience but also increase attack surface when boundaries are not strongly enforced.
– Features designed to make automation more powerful—code execution nodes, shell commands, broad integration access—must be paired with equally strong guardrails.
– Workflows themselves become part of the security perimeter. Their structure, trust assumptions, and I/O handling shape whether a given vulnerability is exploitable in practice.

For organizations, Ni8mare is both a concrete incident to respond to and a broader prompt to reassess the security posture of low‑code and no‑code automation platforms. Centralized automation is now as critical—and as sensitive—as traditional application backends. It must be treated accordingly in threat models, patching priorities, and architecture design.

—