n8n Security Woes Continue: New Critical Flaws Bypass December 2025 Patches
When one 9.9 CVSS vulnerability leads to another, and attackers target the credential vault of modern automation
Executive Summary
The n8n workflow automation platform, with over 100 million Docker pulls and thousands of enterprise deployments, has become a security liability. Between December 2025 and February 2026, security researchers disclosed a cascade of critical vulnerabilities that expose fundamental architectural weaknesses—not just bugs to be patched.
The damage report:
- CVE-2025-68613 (CVSS 9.9): December 2025 arbitrary code execution via expression evaluation
- CVE-2025-68668 (CVSS 9.9): January 2026 "N8scape" Pyodide sandbox escape—a direct bypass of December's fix
- CVE-2026-21858 (CVSS 10.0): January 2026 "Ni8mare" unauthenticated remote code execution affecting ~100,000 servers globally
- Supply chain attack: Malicious npm packages targeting n8n community nodes to steal OAuth tokens from connected services
For organizations running n8n, this isn't a simple "apply patch and move on" situation. The vulnerability pattern reveals systemic issues with how the platform handles code execution isolation—problems that workarounds and version upgrades may not fully resolve.
The December 2025 Vulnerability: CVE-2025-68613
On December 23, 2025, security researcher Fatih Çelik disclosed CVE-2025-68613, a critical arbitrary code execution vulnerability in n8n's expression evaluation engine. The flaw earned a CVSS score of 9.9—just 0.1 points below the maximum severity rating.
Technical Details
The vulnerability exists in how n8n evaluates user-supplied expressions during workflow configuration. According to the official GitHub security advisory:
"Under certain conditions, expressions supplied by authenticated users during workflow configuration may be evaluated in an execution context that is not sufficiently isolated from the underlying runtime."
In practical terms: an authenticated attacker with permission to create or modify workflows could abuse this behavior to execute arbitrary code with the privileges of the n8n process. Successful exploitation leads to:
- Unauthorized access to sensitive data stored in n8n's credential vault
- Modification of workflows across the entire organization
- Execution of system-level operations on the host
Massive Attack Surface
Attack surface management platform Censys identified 103,476 potentially vulnerable instances as of December 22, 2025. The geographic distribution revealed concentration in:
- United States
- Germany
- France
- Brazil
- Singapore
The vulnerability affected all n8n versions from 0.211.0 up to 1.120.4. Patches were released in versions 1.120.4, 1.121.1, and 1.122.0.
Many organizations applied the December patches believing they had addressed the issue. They were wrong.
January 2026: The Bypass (CVE-2025-68668 "N8scape")
Two weeks after n8n released patches for CVE-2025-68613, Cyera Research Labs disclosed a new critical vulnerability that bypassed the December fix entirely. Codenamed "N8scape," CVE-2025-68668 carries an identical CVSS 9.9 rating and exposes a fundamental flaw in n8n's security architecture.
The Pyodide Sandbox Problem
n8n's Python Code Node uses Pyodide—CPython compiled to WebAssembly—to execute user-supplied Python code within workflows. To prevent dangerous operations, n8n implemented a blocklist-based sandbox that restricts access to certain functions.
The blocked functions include:
os.system(command execution)sys.modules['js'](JavaScript bridge)Object.constructor.constructorpath (JavaScript execution)
However, researchers Vladimir Tokarev and Ofek Itach discovered two independent bypass techniques that completely circumvent these restrictions.
Bypass #1: ctypes to libc.system()
The first bypass exploits Python's Foreign Function Interface (FFI) through the ctypes module, which n8n failed to block:
import ctypes
ctypes.CDLL(None).system(b"id; whoami; cat /etc/passwd")
This two-line proof-of-concept demonstrates how an attacker can invoke the system's native system() function directly, bypassing n8n's Python-level blocks entirely. The n8n developers blocked os.system (the wrapper), but the underlying capability remained accessible through ctypes.
Bypass #2: eval_code() Execution Context
The second bypass exploits _pyodide._base.eval_code(), which executes code in a context where n8n's security patches aren't applied:
import _pyodide._base
_pyodide._base.eval_code("import os; os.system('id')")
When n8n initializes Pyodide, it patches dangerous functions by replacing them with stubs that raise security exceptions. But eval_code() runs in a separate execution context where these patches don't exist.
Why Blocklists Fail
Cyera's analysis crystallizes the fundamental security flaw:
"It's a structural problem which stems from a blocklist-based sandbox that implicitly assumes the defender can enumerate every dangerous capability and every path to reach it. CVE-2025-68668 is a weakness in the security model of n8n's Pyodide-backed Python execution: n8n blocks a small set of risky functions, but it does not remove the underlying capabilities."
This architectural criticism matters because it predicts future vulnerabilities. Any system that relies on blocking "known bad" patterns will inevitably be bypassed when researchers (or attackers) discover new paths to the same capabilities.
Affected Versions and Remediation
CVE-2025-68668 affects n8n versions from 1.0.0 up to (but not including) 2.0.0. The vulnerability was patched on December 24, 2025, with version 2.0.0 making the task runner-based native Python implementation the default.
Immediate mitigations if you cannot upgrade:
Enable the task runner-based sandbox:
N8N_RUNNERS_ENABLED=true
N8N_NATIVE_PYTHON_RUNNER=true
Disable Python support in the Code Node:
N8N_PYTHON_ENABLED=false
Disable the Code Node entirely:
NODES_EXCLUDE: "[\"n8n-nodes-base.code\"]"
The Perfect Storm: CVE-2026-21858 "Ni8mare" (CVSS 10.0)
As if two 9.9-rated vulnerabilities weren't enough, Cyera Research Labs disclosed the worst n8n vulnerability yet on January 7, 2026. Codenamed "Ni8mare," CVE-2026-21858 achieves the maximum CVSS score of 10.0 because it enables unauthenticated remote code execution—no credentials required.
The Content-Type Confusion Attack
The vulnerability stems from a logic error in how n8n's Form Webhook Node handles HTTP requests. The exploit chain works as follows:
- Normal flow: When a user uploads a file through an n8n Form, the middleware checks the
Content-Typeheader. If it'smultipart/form-data, the file upload parser (Formidable) processes the file and stores it inreq.body.files. - Attack flow: An attacker intercepts the HTTP request and changes the Content-Type from
multipart/form-datatoapplication/json. This forces n8n to use the regular body parser instead of the file upload parser. - Arbitrary file read: When the Form Webhook processes the "upload," it copies the attacker-specified file (
/etc/passwd) instead of an actual uploaded file—enabling arbitrary file read from the n8n server.
Variable override: The attacker crafts a malicious JSON body that overrides req.body.files:
{
"files": {
"0": {
"filepath": "/etc/passwd"
}
}
}
From File Read to Full Compromise
The arbitrary file read primitive enables a complete authentication bypass and remote code execution chain:
Step 1: Extract the database
The attacker loads /home/node/.n8n/database.sqlite (in Docker deployments) into an n8n workflow, extracting user IDs, emails, and password hashes.
Step 2: Extract the encryption key
The attacker loads /home/node/.n8n/config to obtain the secret key used for signing session cookies.
Step 3: Forge admin session
With the user record data and signing key, the attacker creates a valid n8n-auth JWT cookie, bypassing authentication entirely.
Step 4: Execute commands
Logged in as admin, the attacker creates a workflow using the "Execute Command" node for arbitrary code execution.
100,000+ Vulnerable Servers
Cyera's research indicates approximately 100,000 n8n servers are potentially vulnerable to CVE-2026-21858. The disclosure timeline:
- November 9, 2025: Reported to n8n
- November 10, 2025: Acknowledged
- November 18, 2025: Patched version released
- January 6, 2026: CVE assigned
- January 7, 2026: Public disclosure
Organizations must upgrade to n8n version 1.121.0 or later immediately. There are no workarounds for this vulnerability.
Supply Chain Attack: The Community Node Nightmare
While vulnerability researchers hammered n8n's core platform, threat actors launched a parallel campaign targeting the n8n ecosystem's weakest link: community-contributed nodes.
Attack Mechanics
In January 2026, Endor Labs discovered eight malicious npm packages masquerading as legitimate n8n integrations. The attack exploits a fundamental trust model weakness:
"Community nodes run with the same level of access as n8n itself. They can read environment variables, access the file system, make outbound network requests, and, most critically, receive decrypted API keys and OAuth tokens during workflow execution. There is no sandboxing or isolation between node code and the n8n runtime."
The malicious package n8n-nodes-hfgjf-irtuinvcm-lasdqewriit (4,241 downloads) posed as a Google Ads integration. When installed:
- It displayed legitimate-looking credential configuration forms
- Users entered their Google Ads OAuth tokens
- The package encrypted and stored credentials in n8n's credential store (normal behavior)
- During workflow execution, the package decrypted credentials using n8n's master key
- Credentials were exfiltrated to
n8n-license-validator.onrender.com
Identified Malicious Packages
| Package Name | Downloads | Status |
|---|---|---|
| n8n-nodes-hfgjf-irtuinvcm-lasdqewriit | 4,241 | Removed |
| n8n-nodes-gasdhgfuy-rejerw-ytjsadx | 8,385 | Deprecated |
| n8n-nodes-danev | 5,525 | Removed |
| n8n-nodes-zalo-vietts | 4,241 | Removed |
| n8n-nodes-gg-udhasudsh-hgjkhg-official | 3,150 | Still available |
| n8n-nodes-ggdv-hdfvcnnje-uyrokvbkl | 1,657 | Removed |
| n8n-nodes-vbmkajdsa-uehfitvv-ueqjhhhksdlkkmz | 1,493 | Removed |
| n8n-nodes-performance-metrics | 752 | Removed |
The campaign continues—n8n-nodes-gg-udhasudsh-hgjkhg-official was updated just hours before Endor Labs' public disclosure, suggesting active threat actor engagement.
Why This Attack Matters
n8n isn't just a workflow tool—it's a centralized credential vault. A typical enterprise n8n deployment holds OAuth tokens for Google Workspace, Salesforce, Stripe, Slack, and dozens of other connected services. Compromising n8n means compromising everything connected to it.
To disable community nodes on self-hosted instances:
N8N_COMMUNITY_PACKAGES_ENABLED=false
Understanding the Attack Surface: How n8n Architecturally Enables Compromise
To fully grasp why these vulnerabilities are so devastating, security professionals need to understand n8n's architecture and trust model.
The Central Automation Control Plane
n8n isn't merely a task scheduler—it functions as a central automation control plane that orchestrates actions across an organization's entire digital ecosystem. A typical enterprise deployment might include:
- CRM integrations: Salesforce, HubSpot, Pipedrive workflows that trigger on lead events
- Communication automation: Slack, Microsoft Teams, email systems receiving and sending messages
- Financial operations: Stripe, PayPal, accounting system integrations handling transaction data
- DevOps pipelines: GitHub, GitLab, Jenkins integrations with deployment credentials
- Database operations: Direct connections to PostgreSQL, MySQL, MongoDB production databases
- Cloud management: AWS, Azure, GCP APIs with service account credentials
When an attacker compromises n8n, they don't just gain access to one system—they inherit the trust relationships n8n maintains with every connected service.
The Credential Lifecycle Problem
n8n's credential management follows this lifecycle:
- Storage: Credentials are encrypted using AES-256 and stored in
~/.n8n/database.sqlite - Retrieval: During workflow execution, n8n decrypts credentials using its master key
- Delivery: Decrypted credentials are passed to node code (including community nodes) as plain JavaScript objects
- Execution: Node code has unrestricted access to make authenticated API calls
The critical flaw: once code execution is achieved (via N8scape, Ni8mare, or malicious community nodes), credentials are fully accessible. The encryption that protects credentials at rest provides zero protection against runtime exploitation.
Privilege Escalation Paths
n8n's permission model creates multiple escalation vectors:
| Starting Point | Escalation Path | End State |
|---|---|---|
| Low-privilege user (workflow edit) | N8scape sandbox escape | System-level RCE |
| Unauthenticated attacker | Ni8mare file read → JWT forge | Admin access + RCE |
| Any user installing community node | Malicious node executes | Credential exfiltration |
| Workflow editor access | Create Execute Command node | Arbitrary command execution |
The consistent pattern: every path leads to credential theft and lateral movement into connected systems.
The Bigger Picture: Automation Platforms as Attack Surface
The n8n vulnerability cascade illustrates a broader security reality: workflow automation platforms have become high-value targets precisely because of their operational importance.
The Credential Vault Problem
Modern automation platforms like n8n, Zapier, and Make operate as "credential vaults" holding:
- OAuth tokens for SaaS applications
- API keys for cloud services
- Database connection strings
- Internal service credentials
- Identity provider integrations
A single compromised n8n instance can provide attackers with persistent, trusted access to an organization's entire digital ecosystem.
Agentic AI Amplifies Risk
As organizations adopt agentic AI frameworks, workflow engines like n8n increasingly serve as the execution layer for autonomous AI actions. An AI agent planning and executing business operations relies on n8n to translate decisions into infrastructure changes—making sandbox escapes and code execution vulnerabilities catastrophically dangerous.
The Blocklist Trap
All three major n8n vulnerabilities share a common root cause: reliance on blocklist-based security controls. Whether blocking specific Python functions (N8scape), trusting Content-Type headers (Ni8mare), or assuming community nodes are safe (supply chain), n8n's security model assumes defenders can enumerate all dangerous paths.
This assumption always fails eventually. The only durable solution is capability-based isolation: running untrusted code in environments that fundamentally cannot access sensitive resources, regardless of what clever exploitation paths exist.
CISO Action Plan
Immediate Actions (24-72 Hours)
- Inventory all n8n instances across your organization, including shadow IT deployments
- Verify versions: Any instance below 2.0.0 is vulnerable to N8scape; below 1.121.0 is vulnerable to Ni8mare
- Audit community nodes: List all installed npm packages and compare against known malicious packages
- Check for compromise indicators:
- Unusual outbound connections from n8n hosts
- Workflow modifications by unexpected users
- New admin accounts created
- Credential access patterns outside normal workflows
Short-Term Actions (1-2 Weeks)
- Upgrade to n8n 2.0.0 or later with task runner-based Python isolation
- Disable community nodes unless explicitly required and security-vetted
- Implement network segmentation to limit n8n's access to only required services
- Enable audit logging for all credential access and workflow modifications
- Review n8n permissions: Apply least-privilege principles to user accounts
Long-Term Strategy
- Reassess automation platform risk: Consider whether self-hosted n8n provides adequate security for your threat model
- Implement runtime protection: Deploy container security and behavioral monitoring on n8n hosts
- Credential rotation: Rotate all OAuth tokens and API keys accessible through n8n
- Security architecture review: Evaluate whether n8n should access production credentials directly or use a secrets management layer
Detection and Forensics: Identifying Compromise
Organizations should implement monitoring for n8n-specific attack indicators:
Network-Level Detection
- Outbound connections to suspicious domains: Monitor for n8n hosts connecting to unknown endpoints, particularly during workflow execution windows
- Unusual API traffic patterns: Credential exfiltration may appear as unexpected authentication attempts to connected services
- Data exfiltration signatures: Large file transfers or multiple small requests to non-business endpoints
Host-Level Indicators
# Check for unauthorized command execution
grep -r "system\|exec\|spawn" /home/node/.n8n/logs/
# Identify unexpected file access patterns
auditctl -w /home/node/.n8n/database.sqlite -p r -k n8n_db_read
auditctl -w /home/node/.n8n/config -p r -k n8n_config_read
# Monitor for privilege escalation attempts
grep -E "(ctypes|eval_code|_pyodide)" /var/log/syslog
Application-Level Forensics
- Audit workflow changes: Review all workflow modifications for suspicious Code nodes or Execute Command nodes
- Credential access logs: If logging is enabled, analyze which credentials were accessed and when
- User session analysis: Look for JWT tokens that don't match expected authentication patterns
- Community node inventory: Compare installed packages against known malicious packages list
Incident Response Checklist
If compromise is suspected:
- Isolate immediately: Disconnect n8n from network; preserve all logs and database files
- Credential rotation: Treat ALL credentials stored in n8n as compromised; rotate immediately
- Connected system audit: Review authentication logs for all services n8n had access to
- Timeline reconstruction: Map when vulnerability was exploited using file timestamps and logs
- Lateral movement assessment: Check if attackers moved from n8n to connected systems
Lessons for the Industry: Beyond n8n
While this analysis focuses on n8n, the vulnerabilities reveal patterns applicable to all workflow automation platforms:
The Sandbox Fallacy
Any platform that allows user-supplied code execution faces the sandbox challenge. n8n's Pyodide blocklist approach failed for the same reason sandboxes consistently fail: they attempt to restrict capability at the wrong layer.
Alternative architectures that provide stronger isolation:
- Process isolation: Running user code in separate processes with restricted system call access (seccomp, AppArmor)
- Container isolation: Each workflow execution in ephemeral containers with no credential access
- VM-level isolation: Firecracker-style microVMs for complete memory and syscall separation
- Capability-based access: Code receives only specific API tokens, never raw credentials
Supply Chain Universality
The community node attack isn't unique to n8n. Any platform with:
- Third-party extensions/plugins
- Package manager integration (npm, pip, etc.)
- Runtime credential access for extensions
...faces identical supply chain risks. Organizations must apply the same vetting rigor to automation platform plugins as they do to production dependencies.
Automation Platform Security Maturity Model
| Level | Description | Controls |
|---|---|---|
| 0 - Ad Hoc | Default installation, no security controls | None |
| 1 - Basic | Updated to latest version, basic authentication | Patching, auth |
| 2 - Managed | Network segmentation, logging enabled | Segmentation, audit logs |
| 3 - Defined | Formal change control, community nodes reviewed | Change management, extension vetting |
| 4 - Measured | Runtime monitoring, credential rotation policies | EDR/behavioral monitoring, secrets management |
| 5 - Optimizing | Capability-isolated architecture, continuous assessment | Process isolation, red team exercises |
Most organizations with n8n deployments operate at Level 0-1. The vulnerability cascade demonstrates why Level 3+ should be the minimum standard.
Conclusion
The n8n vulnerability cascade represents more than a series of bugs—it exposes architectural assumptions that consistently fail under adversarial pressure. When security researchers find a 9.9 CVSS vulnerability, patch it, and immediately find another 9.9 bypass, the problem isn't inadequate patching. The problem is inadequate architecture.
For security teams, the message is clear: workflow automation platforms are now critical infrastructure that demand the same security scrutiny as production databases and identity providers. The convenience of centralized automation cannot come at the cost of centralized compromise.
Organizations that treat n8n as "just a productivity tool" will find themselves explaining to their board how a workflow automation platform became the entry point for a catastrophic breach.