Unpacking n8n RCE CVE-2025–68613

If you work in tech, you know n8n. It’s the Swiss Army knife of workflow automation the glue connecting your SaaS apps, internal APIs, and…

Unpacking n8n RCE CVE-2025–68613

If you work in tech, you know n8n. It’s the Swiss Army knife of workflow automation the glue connecting your SaaS apps, internal APIs, and databases. It’s powerful, it’s visual, and as of December 19, 2025, it’s also the carrier of a 9.9 CVSS critical vulnerability.

We aren’t talking about a minor bug here. We are talking about Remote Code Execution (RCE).

In this deep dive, I’m going to break down exactly how CVE-2025–68613 works, why it’s so dangerous, and how you can detect if someone is trying to use it against you.

The “Oh S**t” Moment

The vulnerability lies in n8n’s Workflow Expression Evaluation System.

For those uninitiated, n8n allows you to use dynamic data in your nodes using double curly braces {{ }}. These expressions are evaluated as JavaScript. The problem? Versions 0.211.0 through 1.120.3 didn't sandbox these expressions correctly.

The system assumed that authenticated users (people with logins) were trustworthy. It also assumed that its execution context was isolated enough to prevent damage. It was wrong.

An attacker with basic access can inject a JavaScript payload that escapes the sandbox, accesses the Node.js global scope, and executes system-level commands with the privileges of the n8n process.

Anatomy of the Exploit

Let’s look at the actual payload pattern discovered by researchers. It’s a masterclass in JavaScript context escalation.

Detection: Catching the Invisible

Here is the bad news: n8n’s native logs won’t catch this. They log workflow steps, not the raw HTTP body content where this malicious string hides.

To detect this, you need to be looking at the traffic before it hits the app.

Continue reading here as Medium doesn’t allow the inclusion of code snippets in this context.