Critical n8n Vulnerability Lets Attackers Run System Commands Through a Webhook

What Happened

A critical remote code execution vulnerability has been disclosed in n8n, the popular open-source workflow automation platform. Tracked as CVE-2026-25049 with a CVSS score of 9.4, the flaw allows an attacker to escape n8n's expression sandbox and execute arbitrary system commands on the host machine.

What makes this worse: this vulnerability bypasses the fix for CVE-2025-68613 (CVSS 9.9), another critical sandbox escape that n8n patched in December 2025. The previous fix was incomplete — and researchers found a way around it.

If you self-host n8n, this is a patch-immediately situation.

How the Attack Works

n8n lets users write expressions in workflow parameters — things like {{ $json.email }} to reference data flowing through a workflow. These expressions run in a sandboxed JavaScript environment that's supposed to prevent access to the underlying operating system.

The sandbox escape exploits a fundamental mismatch between TypeScript's compile-time type system and JavaScript's runtime behavior.

Here's the core problem:

n8n's sanitization logic checks that expression inputs are strings before processing them
TypeScript's type annotations enforce this at compile time — the code "looks" type-safe
But TypeScript types don't exist at runtime. An attacker can craft inputs that pass non-string values (objects, arrays, symbols) that bypass the sanitization entirely
Once past the sanitizer, the attacker's payload reaches the JavaScript runtime with full access to Node.js APIs — including child_process

The attack chain is straightforward:

Crafted expression → Bypasses string check → Escapes sandbox → Executes system commands

The Webhook Attack Vector

The most dangerous exploitation path uses n8n's webhook trigger:

An attacker creates a workflow with a publicly accessible webhook with no authentication
The workflow contains a malicious expression using JavaScript destructuring syntax
Anyone on the internet can hit that webhook URL and trigger system-level command execution on the n8n host

One line of JavaScript in a workflow parameter. One unauthenticated webhook. Full RCE.

What an Attacker Can Do

Once they have command execution on the n8n host, the impact is severe:

Steal credentials — n8n stores API keys, database passwords, OAuth tokens, and other secrets for all connected services. These are now accessible
Access connected systems — n8n is often connected to databases, cloud providers, email services, CRMs, and internal APIs. The attacker inherits all of these connections
Install backdoors — Persistent access through reverse shells, cron jobs, or modified n8n workflows that phone home
Pivot internally — If n8n runs inside your network (which it usually does), the compromised host becomes a launchpad for lateral movement

n8n is a workflow automation tool, which means it's typically connected to everything. Compromising it often means compromising your entire integration layer.

Are You Affected?

Vulnerable Versions

All n8n versions prior to 1.123.17 (1.x branch)
All n8n versions prior to 2.5.2 (2.x branch)

Check Your Version

# If running n8n via npm
npx n8n --version

# If running via Docker
docker exec <container_name> n8n --version

Patch Immediately

# npm
npm update n8n

# Docker — update to latest image
docker pull n8nio/n8n:latest

Target versions: 1.123.17+ or 2.5.2+

If You Can't Patch Right Now

If an immediate upgrade isn't possible, apply these mitigations:

Restrict workflow creation — Only allow fully trusted users to create or modify workflows. The vulnerability requires the ability to edit workflow expressions
Disable public webhooks — If any workflows use unauthenticated webhooks, disable them immediately
Run n8n with minimal OS privileges — Use a dedicated service account with limited filesystem and network access
Network isolation — Restrict n8n's outbound network access to only the services it needs to reach
Monitor for anomalies — Watch for unexpected process creation, outbound connections, or file modifications on the n8n host

The Recurring Pattern

This is the second critical sandbox escape in n8n in two months. The December 2025 fix (CVE-2025-68613) was supposed to solve this class of vulnerability, but the underlying problem — TypeScript type annotations providing a false sense of runtime safety — wasn't fully addressed.

This pattern is worth paying attention to:

TypeScript types are not runtime guarantees. If your security boundary depends on type checks, you need runtime validation too. TypeScript compiles away to JavaScript — typeof checks at runtime are the only thing that actually matters
Expression engines are high-risk surfaces. Any system that lets users write expressions that get evaluated — whether it's n8n, template engines, spreadsheet formulas, or query builders — is a potential sandbox escape vector
Incomplete patches get re-exploited. When a critical vulnerability gets a fix that doesn't address the root cause, researchers (and attackers) immediately start looking for bypasses

The Bigger Question

n8n is used by thousands of teams to automate workflows that connect sensitive internal systems. It's often deployed with broad network access and credentials to dozens of services. A single RCE vulnerability in n8n doesn't just compromise one application — it compromises an automation hub that touches everything.

If you're self-hosting any workflow automation platform — n8n, Apache Airflow, Temporal, or similar — treat it as a critical security surface. Run it in a hardened environment, restrict who can create workflows, audit what it's connected to, and patch it like your infrastructure depends on it. Because it does.

DevBlacksmith