The Ni8mare Chain: How n8n RCE Turns Auth Bypass Into Linux Host Compromise

A remote code execution issue disclosed in December 2025 did not look unusual at first. Patches were released late last year in versions 1.120.4, 1.121.1, and 1.122.0. It was treated as a routine update.

The issue lies in how workflow expressions are evaluated. User input was not properly isolated from the Node.js runtime. That gap allows an authenticated user to execute code with the same privileges as the n8n process.

On March 11, 2026, CISA added it to the Known Exploited Vulnerabilities catalog. Active exploitation was confirmed, with a March 25 deadline for federal systems. That is where this stops being routine. What looked like a normal patch cycle is now an active exposure window for systems still running older versions.

Actively Exploited n8n RCE Puts Linux and Docker Hosts at Risk

CISA adding this to the Known Exploited Vulnerabilities catalog confirms active exploitation. The patch has been available since December, but exposed systems stayed unpatched. This isn’t a new issue. It’s one that remained unpatched long enough to be exploited.

The n8n vulnerability allows authenticated remote code execution. On its own, that would limit exposure. In practice, attackers are not using it alone. They are pairing it with CVE-2026-21858 (Ni8mare), a separate issue that exposes internal files without authentication.

Those files include session data and encryption keys. Enough to recreate or take over valid sessions.

Ni8mare provides the session, and the n8n RCE executes within it, so the exploit still follows the expected path but no longer depends on legitimate access.

Because Ni8mare targets how n8n handles webhooks, attackers don’t need valid credentials to reach the application, and in many cases, a single exposed webhook or form node is enough to start interacting with the instance and pulling internal data.

Why Linux Admins Should Care About the n8n RCE Vulnerability

n8n usually runs on Linux hosts, most often Ubuntu or Debian, and a lot of deployments go through Docker or Compose, which looks isolated at first glance but sits closer to the host than people expect. The RCE executes with the same privileges as the n8n process, so the access gained reflects what the service already has, which in real environments typically includes:

• /etc and system configuration files
• .ssh directories and private keys
• Environment variables acting as the primary secret store
• Internal APIs and services wired into workflows

That access exposes high-value data directly, including API keys, OAuth tokens, database credentials, and CI/CD secrets. Most of this lives in environment variables or stored configurations, so what starts at the application layer does not stay there and turns into broader Linux system access tied to whatever those credentials can reach.

In newer deployments, that access often extends into AI-related systems. n8n is increasingly used to orchestrate LLM workflows, which means it may have write access to vector databases or internal knowledge stores. Once compromised, that access can be used to modify stored data or influence how downstream systems retrieve and generate information.

Attack activity is not just opportunistic. Proof-of-concept exploit code has been published by researchers, and scanners built around it are already circulating. Exposed n8n instances are easy to identify and target at scale.

How the n8n RCE Vulnerability Leads to Full Linux System Access

At a basic level, n8n lets users build workflows that include small bits of logic called expressions. These are supposed to run in a restricted environment so they can’t affect the rest of the system.

That restriction is where the problem is.

n8n confirmed in their security advisory that these expressions were not properly isolated from the underlying Node.js runtime, which means user-controlled input could break out of that restricted environment and run as normal system code.

Once that happens, the application is no longer in control.

The code runs with the same permissions as the n8n service itself, which allows attackers to execute system commands, read files like /etc/passwd or SSH keys, access environment variables, and modify workflows or behavior.

This is why the impact goes beyond the application. The web interface becomes a direct path to system-level access.

How n8n RCE Leads to Full Linux Host Compromise in Docker Environments

n8n often runs through Docker Compose, and a lot of those setups run containers as root while also mounting /var/run/docker.sock for automation, which means the app isn’t really contained. It has direct access to the Docker daemon on the host. Once RCE lands inside that container, it doesn’t stay there, because talking to Docker is already part of what the service is allowed to do.

With access to the socket, attackers can start new containers, set privileges, mount whatever they want, and the host filesystem is usually the first target. Something as simple as:

docker run --privileged -v /:/host alpine cat /host/etc/shadow

…is enough to read from the host directly, and from there it’s not just file access, it’s the ability to spin up privileged containers and run commands outside the original container entirely, because nothing is being escaped. The access was already there.

Container compromise leads straight to host access in these setups, not because of a complex breakout, but because the configuration hands over control by default, which turns a workflow-level RCE into full Linux host takeover without needing anything extra.

Thousands of Exposed n8n Instances Increase Real-World Risk

Over 24,000 internet-facing n8n instances have been identified, and many are still publicly accessible, weakly authenticated, or running outdated versions, which makes it easy to scan for and exploit at scale. n8n sits in the middle of automation pipelines, so access to one instance usually extends beyond the application itself.

Here’s what that access connects to:

• Cloud services
• Internal APIs
• Databases
• SaaS platforms

In newer deployments, that scope expands further because n8n is being used for AI orchestration, where it often has write access to:

• Vector databases
• Internal knowledge systems
• Automation pipelines tied to sensitive data

That combination of exposure and reach is why this is getting automated, with scanners and proof-of-concept code already circulating in n8n RCE scanner and exploit code already in circulation, because a single exposed instance is rarely just a single system.

What Attackers Do After Exploiting n8n Servers

Once RCE is established, attackers start by pulling what the process already has access to, which usually includes environment variables, connected services, and credentials tied to workflows, all available without changing anything or triggering obvious alerts, and that initial access is enough to map out what the instance is connected to.

From there, the .n8n directory becomes the priority, because it holds the instance encryption key, and once that key is retrieved, attackers can decrypt stored credentials, which typically include:

• AWS credentials
• GitHub tokens
• Slack tokens
• Database access

With credentials exposed, access doesn’t stay tied to the original exploit, and persistence gets layered in through system changes like reverse shells or cron jobs, but also inside n8n itself through modified or injected workflows that run through webhooks or schedules and blend into normal automation.

Those same credentials are then used to pivot into cloud environments, internal networks, and source code repositories, so what started as access to a single service turns into a foothold across connected systems. 

How to Secure n8n on Linux Servers and Docker Environments

If an instance is exposed or was exposed recently, assume access already happened and work from that position, because patching alone doesn’t remove credentials or persistence. This is not a container escape. The access comes from how the container is configured.

Immediate Actions to Secure n8n After RCE Exposure

Start with containment, not patching, because exposed systems should be treated as already accessed.

• Remove public access to n8n immediately (block port 5678 or restrict via firewall/VPN)
• Disable or restrict workflow editing to trusted users only
• Stop or isolate the service if exposure is confirmed

Patching should still be applied, but it does not remove existing access:

• update to:
  • 1.120.4+
  • 1.121.1+
  • 1.122.0+

Assume compromise if the instance was reachable before patching:

• rotate all credentials:
  • API keys
  • OAuth tokens
  • database credentials
  • n8n encryption key

Focus on what the process could access, not just the application itself.

Long-Term Fix: Securing n8n with Task Runner Isolation (2.x)

Patching fixes the bug, but the execution model is what made it exploitable.

• n8n 2.x introduces Task Runner isolation
• Separates execution from the core application
• Reduces sandbox escape risk tied to expression evaluation

Treat 1.122.0 as a short-term fix and plan migration to 2.x.

How to Harden n8n on Linux Servers

Reduce exposure at the service level, not just the application version.

• Remove public access to the n8n UI (port 5678)
• Restrict workflow creation and edit permissions
• Audit user access and roles

Docker Security Fixes for n8n Deployments

Most real-world risk comes from how containers are configured.

• Do not run containers as root
• remove /var/run/docker.sock unless absolutely required
• restrict container capabilities
• segment network access

How to Detect n8n Server Compromise

Look for signs of use, not just presence, because compromised systems often keep running normally.

• Review workflows for unknown nodes or external webhooks.
• Inspect logs for unusual execution patterns or unexpected triggers.
• Check for new users, cron jobs, or unauthorized SSH keys.

n8n Security Checklist: 60-Second Audit

Quick validation of exposure, configuration, and activity.

• Version below 1.122.0 → update immediately
• Port 5678 is publicly accessible → restrict access
• /var/run/docker.sock mounted → remove unless required
• Unexpected /webhook/ POST requests → investigate for Ni8mare activity
• Workflows recently modified → review for unknown changes
• Credentials not rotated after exposure → assume compromise and rotate
• Logs show unusual workflow execution or triggers → trace source and scope

Why the n8n RCE Vulnerability Is More Than a Patch Issue

This started as a workflow bug and turned into system-level access because of where n8n sits and what it connects to. Patching closes the entry point, but it does not remove exposed credentials or undo access that has already been established.

In environments where n8n is tied into automation pipelines, that access often extends beyond the original host into cloud services, internal systems, and anything those credentials touched.