CVE-2026-21877: Critical n8n Arbitrary File Write Vulnerability Leading to Full Remote Code Execution

CVE Summary

CVE ID: CVE-2026-21877
Product: n8n (workflow automation platform)
Vulnerability Type: Arbitrary File Write → Remote Code Execution
Severity: Critical
CVSS (v3.1): ~9.9
Attack Complexity: Low
Privileges Required: Authenticated access
User Interaction: None
Impact: Full compromise of the n8n host or container

Executive Overview

CVE-2026-21877 is a critical security vulnerability in n8n that allows an authenticated user to escalate from standard workflow-level access to full remote code execution on the underlying system. The vulnerability stems from insufficient validation and restriction of file write operations that are reachable through normal application functionality.

Under specific conditions, an attacker can cause n8n to write attacker-controlled files to locations that are later loaded or executed by the n8n runtime. Once this occurs, the attacker’s code executes with the same privileges as the n8n service itself.

In real-world deployments, this typically means access to internal networks, automation secrets, API keys, credentials stored in environment variables, and potentially the underlying operating system. If n8n is running in a container with elevated privileges or mounted host directories, the impact can extend beyond the container boundary.

Both self-hosted and managed deployments are affected if they were running vulnerable versions prior to the official fix.

Technical Root Cause

n8n allows authenticated users to create, modify, import, and execute workflows. These workflows are not purely logical constructs; they are stored, loaded, and processed by the application at runtime. Workflow definitions, metadata, and related artifacts are written to disk or dynamically interpreted by the Node.js runtime.

The vulnerability exists because certain application paths allow user-controlled input to be written to disk without sufficiently strict enforcement of:

Where the file is written
What type of file is written
Whether the file will later be interpreted or executed

In vulnerable versions, a logged-in user can influence file creation in directories that the n8n runtime implicitly trusts. When n8n later loads workflows, plugins, or runtime components, those files may be treated as executable code rather than inert data.

At a high level, the attack chain works as follows:

The attacker gains authenticated access (legitimate account, compromised credentials, shared account, or exposed API token).
The attacker performs a workflow-related action such as an import, upload, or configuration update.
Due to weak path validation or content handling, a file is written into a runtime-relevant directory.
During normal operation, n8n loads or evaluates that file.
Attacker-controlled code executes with the privileges of the n8n process.

If n8n is running as root or with broad filesystem permissions (which is common in containerized or misconfigured environments), the blast radius is substantial.

Why This Is Dangerous Even Though Authentication Is Required

The requirement for authentication does not meaningfully reduce risk in most environments.

Common contributing factors include:

Multiple users with workflow-edit permissions
Service accounts and automation tokens embedded in CI/CD pipelines
Shared or long-lived admin credentials
Lack of MFA enforcement
Credential reuse across internal systems

Once a normal or low-privileged user can trigger arbitrary file writes that lead to code execution, the distinction between “user” and “administrator” effectively disappears. From a security standpoint, this becomes a full platform compromise.

Exploit Availability and Testing Stance

Weaponized exploit payloads or proof-of-concept code are intentionally not circulated here. Providing such material would directly enable system compromise.

That said, this vulnerability can be safely validated in controlled environments using non-destructive methods. Defensive testing should focus on observing behavior and validating detections, not on achieving exploitation.

Safe Testing Approach

Testing must only be performed in an isolated lab environment with no production data or credentials.

Recommended approach:

Deploy a disposable n8n instance that mirrors production paths, permissions, and container configuration.
Use a low-privileged test account with workflow creation or editing rights.
Perform standard workflow actions that involve uploads, imports, or configuration changes.
Attempt to create benign files (for example, .txt files or empty .js files containing only comments).
Observe:
- Where files are written
- Whether files appear in runtime or application directories
- Whether any interpreter processes are triggered afterward
Validate that file creation and process execution are logged and detected.

The objective is to confirm visibility and patch status, not to demonstrate code execution.

MITRE Mapping

CWE-434 – Unrestricted Upload of File with Dangerous Type
ATT&CK T1190 – Exploit Public-Facing Application
ATT&CK T1059 – Command and Scripting Interpreter

These mappings help SOC teams align detection logic and incident response workflows.

Detection Strategy – What Actually Works

Required Log Sources

To reliably detect abuse of this vulnerability, the following log sources are essential:

n8n Application Logs

User ID and username
Workflow ID and node ID
Action type (create, import, update)
Source IP
Timestamp
Payload size

Web Server / Reverse Proxy Logs

HTTP method and URI
Request size
Client IP and headers
Response code

Host Filesystem Monitoring (FIM)

File creation and modification events
Full file path
Owning user
Hash of new or modified files

Process Execution Logs

Parent and child processes
Command-line arguments
Execution user
Working directory

Container Runtime Logs

Container exec events
Writable layer changes
Image vs runtime drift

Network Egress Logs

Unexpected outbound connections
New destinations immediately following workflow changes

High-Confidence Detection Logic

Single indicators are rarely sufficient. High-confidence detection relies on correlation:

A workflow edit or import
Followed shortly by file creation in an n8n runtime directory
Followed shortly by a scripting interpreter being launched

Outside of upgrades or controlled deployments, this sequence is rarely legitimate.

Sigma Rule

title: n8n Suspicious File Write Followed by Script Execution
status: experimental
description: Detects potential abuse of n8n arbitrary file write leading to code execution
logsource:
  product: linux
  service: auditd
detection:
  file_write:
    syscall:
      - open
      - openat
    a0.filename|contains:
      - /usr/src/app
      - /home/n8n
      - /var/lib/n8n
    a2.flags|contains: O_CREAT
  proc_exec:
    EventID: ProcessCreate
    Image|endswith:
      - node
      - nodejs
      - python
      - python3
      - sh
      - bash
  condition: file_write and proc_exec within 1m
level: high

auditd Rules (Linux)

-w /usr/src/app -p wa -k n8n_file_write
-w /home/n8n -p wa -k n8n_file_write
-w /var/lib/n8n -p wa -k n8n_file_write

-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/node -k n8n_exec
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/python3 -k n8n_exec
-a always,exit -F arch=b64 -S execve -F exe=/bin/sh -k n8n_exec

IDS / Network Detection

Large POST or PUT requests to workflow or import endpoints
Abnormally large payload sizes
Repeated workflow modifications from the same user or IP
New outbound connections shortly after workflow changes

Network alerts alone are not definitive but provide valuable context when correlated with host activity.

Incident Response Guidance

If behavior consistent with this vulnerability is detected:

Isolate the affected host or container.
Preserve filesystem state and relevant logs.
Identify and suspend the user account involved.
Rotate all secrets accessible to n8n.
Rebuild the instance from a trusted image.
Apply the patched version and hardening controls.
Review workflow author permissions and access scope.

Hardening Recommendations

Upgrade to the fixed n8n version immediately.
Run n8n as a non-root user.
Restrict writable directories to the absolute minimum.
Avoid mounting application directories as writable in containers.
Enforce MFA and least-privilege access for workflow authors.
Continuously monitor file creation and process execution.
Restrict outbound network access from the n8n host.

Official Patch Information

The vulnerability has been fixed by the n8n maintainers.
All deployments should upgrade immediately.

Official patch and release notes:
https://github.com/n8n-io/n8n/releases

Final Takeaway

This is not a theoretical issue. Arbitrary file write in a runtime environment is one of the most dangerous vulnerability patterns, especially in automation platforms that already have deep access into internal systems.

Detection, access control discipline, and immediate patching are the only safe responses.