CVE-2026-27493 Explained: Unauthenticated Zero-Click RCE in n8n

Isha Sangpal

— 7 min read
CVE-2026-27493 Explained: Unauthenticated Zero-Click RCE in n8n

Workflow automation platforms sit at the heart of modern operations. They move data between SaaS tools, internal services, cloud infrastructure, and databases. In practice, that makes them more than just “automation software.” They become high-trust integration hubs that store secrets, hold privileged tokens, and often run with broad network access.

So when a critical vulnerability lands in a platform like n8n, the risk is rarely limited to one workflow. It can turn into a full-environment incident.

CVE-2026-27493 (CVSS 9.5) is exactly that kind of event: a critical, unauthenticated, zero-click remote code execution (RCE) vulnerability affecting n8n. The bug was reported by Pillar Security and is rooted in a deceptively common class of failures: double evaluation, where the system processes user-controlled input twice and accidentally turns “data” into “code.”

This article breaks down the vulnerability in a clear, technical way: the attack surface, the mechanics behind the double evaluation flaw, how it becomes expression injection, and how a sandbox escape can convert it into full server compromise. We’ll end with concrete remediation and hardening guidance defenders can apply immediately.

n8n’s core value is connectivity. It’s designed to orchestrate steps across services like:

  • Cloud platforms such as AWS
  • Internal HTTP services and databases
  • Collaboration tools such as Slack
  • Third-party APIs and SaaS products

To do that, it commonly stores:

  • API keys
  • OAuth refresh tokens
  • Database credentials
  • Webhook secrets
  • Internal endpoints and routing logic

That combination creates a dangerous reality: compromising the n8n server frequently means compromising everything n8n can reach.

CVE-2026-27493 in One Sentence

An attacker can send a crafted payload to a public n8n Form node and trigger unintended expression evaluation, which, when chained with a sandbox escape, results in unauthenticated, zero-click RCE on the n8n host.

The key point is “public-facing.” You do not need an account. You do not need to click anything. If the Form endpoint is reachable, the exploit path exists.

Analyzing the Attack Surface: Publicly Exposed Endpoints

n8n workflows often start with triggers. One of the most common is the Form node, which generates a public endpoint, typically used for contact forms, intake forms, and lightweight data collection.

Examples look like: https://n8n.company.com/form/contact-us

These endpoints are intentionally exposed to untrusted internet traffic, which is fine, as long as the inputs are treated purely as data.

The problem is what happens next: real workflows frequently echo user input back into a confirmation page or a follow-up step (“Thanks for reaching out, John!”). That interpolation step is where the boundary between untrusted input and executable logic can blur.

n8n relies heavily on expressions to make workflows dynamic. A crucial detail here:

  • If a string begins with =, n8n treats what follows as an expression rather than a literal string.

This is powerful when the value is controlled by the workflow author. It becomes dangerous when an attacker can inject it through a public interface.

The Root Cause: Understanding Double Evaluation Vulnerabilities

The vulnerability is described as a double-evaluation flaw. Conceptually, n8n processes the input in two passes:

  1. Pass 1: Template construction / interpolation: The user’s input is inserted into the form confirmation content or into fields that will later be rendered.
  2. Pass 2: Expression evaluation on the newly built output (the fatal step): In prepareFormFields, n8n parses the constructed content again. If the content now contains something that looks like an expression, especially something starting with = , it gets evaluated.

This second pass is where the system crosses the line from “render user text” to “execute user-supplied logic.”

Exploit Mechanics: Achieving Expression Injection

If a form field is expected to contain something benign like a name, an attacker can supply a payload that begins with =. The page explains a conceptual example like:

= $execution.id

Instead of rendering as literal text, the second evaluation resolves it as an expression, producing an internal value (like the workflow execution ID). That is the moment you know you’ve achieved expression injection.

Expression injection is already severe: it can enable attackers to read sensitive values, alter workflow logic, and potentially exfiltrate secrets. But there is an important nuance:

Expression injection is not automatically OS-level RCE.

For that, the attacker needs to break out of the sandbox.

n8n evaluates expressions inside a restricted JavaScript sandbox. The goal is to allow safe computation without exposing Node.js internals.

In many systems, that sandbox boundary is the last real line of defense. If it holds, the attacker may still cause damage (data exposure, workflow manipulation), but not arbitrary command execution on the host.

CVE-2026-27493 becomes truly critical because the injection can be chained with a separate weakness that enables a sandbox escape.

Chaining Vulnerabilities: Escaping the JavaScript Sandbox

The page describes a second issue: CVE-2026-27577, tied to n8n’s AST compiler component @n8n/tournament. Specifically, the issue involves how the compiler handles JavaScript SpreadElements.

The high-level chain looks like this:

  1. The public Form endpoint gives the attacker a path to inject data that becomes executable expressions.
  2. Those expressions can be shaped into structures that the AST compiler processes.
  3. A bug in SpreadElements handling allows bypassing sandbox assumptions.
  4. Once out of the sandbox, the attacker can access the global Node.js context.
  5. With Node context, standard modules like child_process become reachable.
  6. That enables execution of arbitrary shell commands on the server.

The page includes a conceptual payload description, illustrating that the = triggers expression evaluation, and that constructor-style access can pivot into Node.js globals. The exact payload details matter less than the design lesson:

If untrusted input can reach a dynamic evaluator, and the sandbox is imperfect, RCE becomes a matter of chaining.

Zero-Click Exploitation: Bypassing User Interaction

“Zero-click” can be an overloaded term, but here it’s straightforward:

  • The attacker sends a crafted request to the public form endpoint.
  • n8n processes the input automatically.
  • The vulnerable logic evaluates the input without requiring any interactive steps.
  • The exploit runs as part of the form handling / rendering.

No authenticated session. No administrator approval. No user interaction.

Post-Exploitation Impact: From Initial Access to Full RCE

If exploitation succeeds, the attacker is no longer operating “inside a workflow.” They are operating on the host.

That can enable:

  • Theft of secrets from environment variables and filesystem
  • Extraction of stored credentials and tokens used by workflows
  • Lateral movement into internal services reachable from the n8n host
  • Tampering with workflows to persist access or silently exfiltrate data
  • Full compromise of the automation layer that many teams trust for business-critical operations

Because n8n often has broad integration permissions, the effective impact frequently resembles a “central nervous system breach,” not a single-app compromise.

Technical Patch Analysis: Neutralizing the Injection Vector

n8n addressed the issue quickly and released patched versions:

  • 1.123.22
  • 2.9.3
  • 2.10.1

Primary Mitigation: Remove the Second Evaluation Path

The fix centers on eliminating the double-evaluation vector:

  • The risky loop that re-evaluated expressions in form rendering logic was removed.
  • The implementation shifted toward a safer single-pass parsing approach (parseFormFields), treating user input as literal text even if it begins with =.

This is the most important design correction: never re-run an evaluator on content that contains user-controlled fragments.

Defense in Depth: Harden the Sandbox

Beyond removing the injection vector, the patch also hardened the sandbox environment, explicitly blocking access to Node.js globals such as:

  • process
  • require
  • module

This matters because secure engineering assumes that injection bugs can reappear. If you harden the sandbox, you reduce the chance that the next injection bug becomes full RCE.

Remediation Guide: How to Secure and Harden Your Environment

Patch Immediately

Upgrade n8n to one of the patched versions or newer:

  • 1.123.22+
  • 2.9.3+
  • 2.10.1+

If you operate multiple environments (dev, staging, prod), treat this as an emergency patch across all public-facing instances. Attackers routinely scan for exposed automation endpoints after disclosures.

Temporary Mitigation: Disable the Form Node

If you cannot patch immediately, disable the vulnerable functionality by excluding the Form node module:

export NODES_EXCLUDE=n8n-nodes-base.form

This is not a long-term fix, but it can buy time by removing the exposed attack surface while patching is planned.

Audit Exposure: Find Public Entry Points

Review and inventory workflows that accept unauthenticated requests:

  • Form nodes
  • Public webhooks
  • Any workflow step that returns user-controlled content back to a browser

Prioritize anything that echoes input into templates, HTML, or downstream evaluators.

Assume Credential Exposure If Compromise Is Suspected

Because n8n may store and use privileged tokens:

  • Rotate API keys and OAuth credentials used by workflows
  • Review outbound connections from the n8n host
  • Check workflow history and configuration for unauthorized changes
  • Inspect server logs and process execution telemetry for suspicious child processes

Security Architecture: The Risks of Dynamic Evaluation

CVE-2026-27493 is a sharp reminder that modern automation and low-code platforms are extremely powerful, and therefore extremely sensitive to evaluation mistakes.

The vulnerability chain demonstrates a common pattern:

  1. A system adds convenience features (“just prefix with = to make it dynamic”).
  2. A rendering or processing layer accidentally evaluates user content.
  3. A sandbox limits damage, but the sandbox has edge cases.
  4. Two “almost manageable” issues chain into a full compromise.

In environments where automation servers are internet-facing and deeply credentialed, that chain can be catastrophic.

Conclusion

CVE-2026-27493 is not just another injection bug. It is a high-impact, real-world example of how double evaluation can collapse the boundary between data and code, and how sandbox escapes turn expression injection into full unauthenticated RCE.

If you run n8n, the response is straightforward:

  • Patch to a fixed version immediately.
  • If patching is delayed, disable the Form node to remove the exposed attack path.
  • Audit public-facing endpoints and treat workflow automation servers as high-value infrastructure that deserves the same rigor as identity systems and CI/CD.

References & Further Reading

Read more