n8n Vulnerability RCE: Patch Your Self-Hosted Instance Now (CVE-2026-1470)

If you run n8n on a self-hosted Linux server, check your version today. A critical n8n vulnerability RCE tracked as CVE-2026-1470 carries a CVSS score of 9.9. Any authenticated user who can create or edit workflows can use it to escape the JavaScript sandbox and run arbitrary commands on your server. A second flaw, CVE-2026-0863 (CVSS 8.5), does the same through the Python executor. Both are patched. But self-hosted deployments do not update themselves.

Why This n8n Vulnerability RCE Is Especially Dangerous

n8n is a workflow automation platform that connects services and triggers actions automatically. A typical deployment holds API keys for cloud providers, database connection strings, OAuth tokens for SaaS apps, and webhook secrets for every integration it manages.

According to Orca Security’s CVE-2026-1470 analysis, compromising n8n does not give attackers just one server. It gives access to everything n8n connects to. If your instance holds AWS credentials, Slack tokens, and a database connection, an attacker exploiting this flaw has all of those in one shot.

JFrog researcher Natan Nehorai, who found both flaws, explained the mechanism: n8n uses an AST-based sandbox to block dangerous JavaScript before execution. CVE-2026-1470 exploits a missed edge case with the deprecated JavaScript with statement. It makes malicious code look safe during the sandbox inspection and then behaves maliciously at runtime. The vulnerability scored 9.9 because any workflow user can exploit it, not just admins.

Check Your n8n Version: CVE-2026-1470 RCE Exposure

Run this to see your current version:

# npm global install
n8n --version

# Docker
docker exec n8n n8n --version

# Docker Compose
docker compose exec n8n n8n --version

Here are all the n8n CVEs in 2026 and the patched versions for each:

If your version is below the patched releases above, update before doing anything else.

How to Update n8n on Linux

npm global install

npm update -g n8n
n8n --version

Docker

docker pull n8nio/n8n:latest
docker stop n8n && docker rm n8n
docker run -d   --name n8n   -p 5678:5678   -v n8n_data:/home/node/.n8n   --restart unless-stopped   n8nio/n8n:latest
docker exec n8n n8n --version

Docker Compose

docker compose pull
docker compose up -d
docker compose exec n8n n8n --version

systemd service

systemctl stop n8n
npm update -g n8n
systemctl start n8n
systemctl status n8n

Lock Down While You Prepare the Update

If a maintenance window is needed before patching, reduce exposure right now:

# Block public access to n8n port if it is internet-facing
ufw deny 5678/tcp

# Restrict to trusted IPs only
ufw allow from 192.168.1.0/24 to any port 5678

# Review who has workflow editor permissions
# n8n admin panel -> Settings -> Users
# Remove workflow edit access from anyone who does not need it

The Dark Reading coverage of CVE-2026-1470 notes that exploitation requires workflow creation or editing access. Reviewing that permission list and removing unnecessary access is a meaningful short-term mitigation.

Rotate Credentials After Patching

After updating, check whether your instance was accessed while vulnerable. Look through n8n logs for unusual workflow runs:

# systemd logs
journalctl -u n8n --since "7 days ago" | grep -i "execute\|workflow\|error"

# Docker logs
docker logs n8n --since 168h | grep -i "execute\|workflow"

# Check outbound connections from the n8n port
ss -tlnp | grep 5678

Even if nothing looks suspicious, rotate the credentials stored in n8n anyway. This covers API keys, database passwords, OAuth tokens, and webhook secrets. Go to n8n admin panel → Credentials, work through the list, regenerate each secret at the provider, and update n8n with the new value.

The Broader Problem With Automation Platform Security

n8n is one of several automation platforms with serious vulnerabilities in 2026. The pattern is logical from an attacker’s view. Automation platforms sit at the centre of every service they connect. A single exploit gives access to the entire integration ecosystem. For teams running n8n on Linux, the server hardening that protects the OS also limits the blast radius if the application is compromised. Strong firewall rules, minimal accounts, and SSH key hygiene all reduce what an attacker can do after breaking out of the application sandbox. Our Linux server hardening checklist covers all of those layers. If you run local AI models on the same server, also see our guide on installing Ollama on Linux for keeping AI services isolated from automation workloads.

Summary

The n8n vulnerability RCE picture in 2026 is serious. CVE-2026-1470 (CVSS 9.9) plus four additional critical flaws mean any unpatched self-hosted n8n instance is a priority target. Check your version now, update to the patched release, restrict workflow editor access, and rotate stored credentials. n8n Cloud users are already protected. Self-hosted users are not automatically updated. Do it today.