n8n's recurring RCE surface: an automation hub that holds every credential

In brief Through the first half of 2026, n8n — a popular open-source workflow platform used to build LLM-powered agents and automations — has patched a steady run of critical remote-code-execution flaws: an unauthenticated file-read chain disclosed in January 2026, an expression-evaluation family reworked across the spring, and a June 2026 batch that added a Python Code Node sandbox escape and a prototype-pollution path to RCE. None of these is exotic on its own. Together they illustrate a structural problem: an automation hub that holds every one of your credentials is a crown-jewel target, and each individual bug detonates against the same shared secret store. This is a class writeup, not an exploit guide.

What is this?

n8n is a self-hostable workflow-automation engine — think of it as glue that wires together your Google Drive, OpenAI or Anthropic API keys, Salesforce, databases, payment processors, CI/CD, and increasingly LLM agent nodes that call tools and models on your behalf. Roughly a hundred thousand instances are reachable on the public internet, and researchers at eSecurity Planet counted over 103,000 exposed to at least one recent flaw.

The reason n8n keeps appearing in advisories is not that it is uniquely badly written. It is that a workflow engine is, by design, a machine for turning attacker-supplied input into evaluated logic and outbound API calls, while sitting on top of the most sensitive secret store in the building. In the first half of 2026 the project shipped fixes for several distinct root causes — a content-type confusion leading to arbitrary file reads (disclosed January 2026 by Cyera Research Labs as “Ni8mare”), a run of expression-evaluation escapes patched and re-patched through the spring, a global prototype-pollution flaw reachable through an unvalidated pagination parameter, and a Python Code Node sandbox escape published in June. Different bugs, one blast radius.

How it works

There is no single payload here; there is a repeating shape. Across the flaws, the pattern looks like this:

The n8n RCE pattern (conceptual, redacted)
-----------------------------------------
1. An entry point accepts untrusted input
   (a form webhook, an HTTP request parameter, a workflow field)
2. That input reaches an evaluation surface
   - values prefixed to be treated as an expression -> double-evaluation
   - a code node whose sandbox does not fully constrain the runtime
   - an object-merge path that pollutes a shared prototype
3. Evaluation yields file reads, config/secret disclosure, or code execution
4. Whatever the attacker reaches, they reach the credential store
   -> API tokens, OAuth grants, DB connections, the instance secret key

The January chain was the loudest because it needed no login: a request with the wrong content type was parsed by the wrong routine, which let an unauthenticated caller read local files — including the instance secret key and the user database — and from there forge an administrator session and add a command-execution node. The June issues are narrower: they generally require an authenticated account with permission to edit workflows, which scopes them to insider misuse or a stolen editor session. But “narrower” is relative when a single compromised editor can pivot a Python node out of its sandbox onto the task-runner container, or pollute a prototype into host code execution. The expression-evaluation family is the most instructive: n8n treats a field value beginning with a specific prefix as an expression to evaluate, and once user data is evaluated rather than read, the only thing standing between that and RCE is the sandbox — which has now been escaped more than once.

Why it matters

The lesson is not “n8n is unsafe,” it is “orchestration platforms are load-bearing, and we keep securing them like ordinary web apps.” An LLM automation hub concentrates authority the way a domain controller concentrates identity: every workflow you build hands it another long-lived credential, so the value of a single RCE grows with every integration you add. As Cyera put it, a compromised instance does not mean losing one system — it means handing over the keys to everything wired into it.

This matters more, not less, as these platforms sprout agent nodes. An LLM node turns retrieved documents, tool outputs, and chat messages into another untrusted-input channel feeding the same evaluation and credential surfaces. Indirect prompt injection and classic expression injection start to rhyme: both are “attacker-controlled data reaches a place where it gets interpreted.” When the interpreter sits on your secret store, the severity ceiling is the whole environment.

Defenses

1. Patch aggressively and track the branch, not a version. n8n backports fixes across release lines (for example the June sandbox-escape fix landed on the 1.123.x, 2.21.x, and 2.22.x branches). Pin to the latest patch on your branch and watch the project’s security advisories directly, since release notes are intentionally delayed.
2. Get it off the public internet. The exposed-instance counts are the real story. Put n8n behind authenticated ingress or a VPN; an automation hub has no business being world-reachable.
3. Least-privilege the editors. Most of the June flaws require workflow-edit rights. Restrict who can author or modify workflows, review change history, and treat workflow edit permission as a sensitive grant, not a default.
4. Constrain and isolate code/expression nodes. Disable the Python and Form/Code nodes where they are not needed (via the node-exclusion configuration), run task runners in an isolated network segment, and apply egress filtering so a sandbox escape cannot phone home or reach internal services.
5. Rotate and compartmentalize secrets. Assume a hub compromise means total credential loss: scope tokens narrowly, prefer short-lived credentials, alert on unexpected outbound connections from the runner, and rotate anything n8n could read if you suspect abuse.

Status

Item	Reference	Date	Notes
Unauthenticated file-read → RCE (“Ni8mare”)	CVE-2026-21858 (Cyera)	2026-01-07	CVSS 10.0; content-type confusion, patched in 1.121.0 (Nov 2025)
Expression evaluation escape → RCE	CVE-2025-68613 and follow-ups	2026 (re-patched)	Authenticated workflow editor; expression treated as code
Prototype pollution → RCE	CVE-2026-44789	2026-06	CVSS 9.4; unvalidated pagination param in HTTP Request node
Python Code Node sandbox escape	CVE-2026-49444	2026-06-23	CWE-20; authenticated editor escapes to task-runner container; fixed 1.123.48 / 2.21.8 / 2.22.4
Exposure	eSecurity Planet	2026	~103,000 instances reachable and affected by a recent flaw

The honest framing is that none of these bugs is a novel attack. They are the oldest failure modes in web software — parser confusion, evaluated input, weak sandboxes, prototype pollution — landing on infrastructure whose entire job is to hold your credentials and act on your behalf. That is exactly why they keep making the news, and exactly why the automation hub deserves the same suspicion you would give a domain controller.