n8n Critical CVEs (Feb 2026): Who's Affected and How to Patch

Urgent: if you self-host n8n, stop what you’re doing and update immediately. Two critical remote code execution (RCE) vulnerabilities have been discovered that could let any authenticated user take complete control of your server.

Immediate action required. Update to n8n version 1.123.17 or later immediately. These vulnerabilities are rated CVSS 9.9 (critical) and 8.5 (high), and proof-of-concept exploits exist. Patch now.

CVE-2026-1470 (JavaScript Expression RCE) scores CVSS 9.9, critical. CVE-2026-0863 (Python Code Node RCE) scores CVSS 8.5, high.

What Happened: The Technical Details

Two critical security flaws were discovered in n8n’s sandbox mechanisms, the security layers designed to prevent malicious code execution inside workflows. Both let authenticated users escape the sandbox and execute arbitrary code on the host server.

CVE-2026-1470: JavaScript expression sandbox escape

This vulnerability affects n8n’s expression evaluation system, the {{ }} syntax used throughout workflows to access and transform data. The flaw lies in how n8n validates the abstract syntax tree (AST) of JavaScript expressions.

// Vulnerable pattern (do not use): attacker crafts an expression
// that bypasses AST validation
{{ $json['constructor']['constructor']('return process')().mainModule.require('child_process').execSync('whoami') }}

The n8n team intended to block dangerous constructs like require(), process, and constructor chains. Researchers at JFrog found techniques to bypass those filters through creative property-access patterns. The AST validator checks for prohibited function calls and property accesses, but that validation happens before expression evaluation, and certain JavaScript runtime behaviors like prototype-chain traversal aren’t captured by static AST analysis. That gap lets attackers construct valid-looking expressions that execute malicious code at runtime.

CVE-2026-0863: Python Code node sandbox escape

This vulnerability affects Python Code nodes running in Internal execution mode. It exploits Python’s exception-handling mechanism to break out of the restricted execution environment: an attacker raises an exception, catches it, and climbs the call stack via __traceback__ to escalate toward arbitrary code execution.

When running in External mode (Docker sidecars), the impact is reduced because exploits stay contained within isolated containers. Internal mode, the default for many self-hosted installations, provides no such isolation.

Patched versions. CVE-2026-1470 (JavaScript RCE): n8n 1.123.17+ (LTS), 2.4.5+ (current), 2.5.1+ (latest). CVE-2026-0863 (Python RCE): n8n 1.123.14+ (LTS), 2.3.5+ (previous), 2.4.2+ (current).

Who’s Affected

Higher risk: self-hosted n8n with multiple users, Internal execution mode (the default), an instance accessible from the internet, shared workflow-editing permissions, or imported third-party workflows.

Lower risk: n8n Cloud (already patched), External execution mode (Docker), single-user installations, air-gapped environments, or instances already updated.

Organizations using n8n for critical automation face real risk here, since a compromised instance typically has access to API keys for multiple services, database credentials, internal network access, and the ability to modify business-critical automation. The blast radius extends well beyond n8n itself.

Why This Matters for Automation Teams

Automation platforms like n8n are attractive targets precisely because they’re integration hubs. A single compromised instance often provides access to dozens of connected services: CRMs, databases, payment processors, communication tools, and more.

Three realistic attack patterns worth understanding: an insider with basic workflow access can hide malicious code inside an Expression node and exfiltrate data using the server’s own credentials, with logs showing normal operation the whole time. A poisoned public workflow template can carry obfuscated malicious expressions that phone home the moment an unsuspecting team imports and runs it. And an attacker who compromises one contractor’s n8n account can use the sandbox escape to get shell access, then pivot across whatever internal network that server can reach, since n8n often runs with broad outbound access for integrations.

Immediate Action Required

Step 1: check your version.

# Check n8n version
n8n version

# Or via Docker
docker exec n8n n8n version

If your version is below 1.123.17, you’re vulnerable.

Step 2: update immediately.

# Docker Compose
docker pull n8nio/n8n:latest
docker-compose down && docker-compose up -d

# npm
npm update -g n8n

Step 3: verify. Run n8n version again and confirm it reports 1.123.17 or higher.

If you genuinely cannot patch right away, restrict workflow editing to administrators only, disable Python Code nodes if possible, review all recently created or modified workflows for suspicious expressions, and consider taking the instance offline until patched.

Hardening Your n8n Instance

Patching fixes these specific flaws; defense in depth protects against the next ones. Run code nodes in External execution mode so any future sandbox escape stays contained at the container level (EXECUTIONS_MODE=queue, N8N_RUNNERS_ENABLED=true). Implement role-based access control: most users only need read-only access, editor access should go to trusted team members, and permissions deserve a quarterly review. Segment your network so n8n doesn’t have blanket access: place it in its own VLAN, whitelist only the outbound connections it actually needs, and block access to internal management interfaces. Enable audit logging (N8N_LOG_LEVEL=info, N8N_LOG_OUTPUT=file, N8N_LOG_FILE_LOCATION=/var/log/n8n/) so you can reconstruct what happened if something does go wrong. After patching, rotate every credential n8n had access to: API keys, database credentials, OAuth tokens, and SMTP credentials.

Lessons for Self-Hosted Automation

Building a genuinely secure sandbox for arbitrary code execution is hard. Even mature platforms with dedicated security teams miss bypass techniques, so assume any sandbox can eventually be escaped and layer your defenses accordingly.

Integration hubs are high-value targets precisely because they connect to everything, which is also their entire value proposition, so a single compromise can cascade across your whole stack. Treat your automation platform as critical infrastructure, not a side tool.

Self-hosting gives you control, and control comes with responsibility: monitoring security advisories, applying patches promptly, and running proper access controls. If your organization can’t commit to that cadence, a managed option is worth considering. And never import workflows from untrusted sources without review, treat a shared workflow template the way you’d treat any third-party code.

If you want a hardened, self-hosted n8n stack built and monitored properly, including queue-mode execution, RBAC, and audit logging from day one, let’s talk.