n8n CVE-2025-68613: When Workflow Automation Goes Wrong

Hey security enthusiasts! Today we’re diving into a fascinating (and scary) vulnerability in n8n - CVE-2025-68613. This one’s particularly interesting because it shows how even helpful automation tools can become dangerous when security boundaries aren’t properly enforced.

What is n8n and Why Should You Care?

n8n is a popular open-source workflow automation platform that lets you visually connect different applications and services. Think of it as a digital Swiss Army knife for automating repetitive tasks - from sending emails to processing data and integrating various APIs.

The platform is commonly deployed in three ways:

• Self-hosted instances: Organizations run it on their own infrastructure for maximum control
• Cloud-hosted (n8n.cloud): Managed service for those who prefer convenience
• Internal automation tools: Deployed within corporate networks to streamline business processes

What makes n8n powerful is its visual workflow builder and support for over 400 integrations. But as we’ll see, this flexibility comes with some serious security implications.

The Vulnerability: When Expressions Become Dangerous

Here’s where things get interesting (and concerning). Versions 0.211.0 through 1.120.3 contain a critical remote code execution vulnerability in the workflow expression evaluation system.

The problem lies in how n8n handles user expressions wrapped in double curly braces {{ }}. These expressions are supposed to be evaluated safely, but the implementation has a fatal flaw - it doesn’t properly sandbox the execution context.

Technical Deep Dive

n8n’s architecture includes several key components:

• Workflow Execution Engine: The brain that orchestrates everything
• Expression Evaluation System: Processes those {{ }} expressions as JavaScript code
• Code Nodes: Allow custom JavaScript or Python code in workflows
• 400+ Native Integrations: Pre-built connectors for various services

The vulnerability exists because authenticated users can inject malicious JavaScript expressions that escape the intended sandbox and access Node.js internals.

The Exploit: Breaking Down the Attack

Let’s examine the working payload that demonstrates this vulnerability:

{{ (function(){ return this.process.mainModule.require('child_process').execSync('id').toString() })() }}

This might look complex, but let’s break it down step by step:

Step 1: The Anonymous Function Pattern

(function(){ ... })()

This creates and immediately executes an anonymous function - a common JavaScript pattern for encapsulating complex logic.

Step 2: Context Escalation Chain

The exploit follows a clever escalation path:

1. Start with this: References the global object in Node.js
2. Access process: Node.js global object for system processes
3. Reach mainModule: References the root module of the application
4. Use require(): Node.js module loading function (should be restricted!)
5. Load child_process: Core Node.js module for executing system commands
6. Execute commands: Run arbitrary system commands with execSync()

The Security Boundary Breach

The real problem here is that user expressions should never have access to:

• Node.js’s module system
• Dangerous modules like child_process
• The ability to execute system commands

But due to improper sandboxing, attackers can escalate from a simple expression evaluator to full system command execution.

Hands-On Exploitation

Let’s see this vulnerability in action. I’ll walk you through the exploitation process step by step.

Setting Up the Attack

First, we need to log into the vulnerable n8n instance:

After logging in with the provided credentials, we start by creating a new workflow:

Click “Start from scratch” to begin with a clean slate:

Building the Malicious Workflow

Now we need to add our first step. Search for and add a “Manual Trigger”:

Next, we attach an “Edit Fields (Set)” node to our manual trigger:

Executing the Payload

Here’s where the magic happens. Click “Add Field” and:

1. Set the name to something like “exploit” or “result”
2. Paste our malicious payload in the value field
3. Click “Execute step”

And boom! The command executes successfully:

Going Further

Since we can execute arbitrary commands, let’s explore the system. We can replace id with ls to see what files are available:

And then use cat to read files:

The flag reveals itself: THM{n8n_exposed_workflow}

Detection and Defense

Now that we understand how this attack works, let’s talk about detection and prevention.

Detection Strategies

The best approach is to set up a proxy solution (like nginx) to log request bodies and monitor for suspicious patterns. Here’s a sample nginx configuration:

http {
    # Custom log format to capture request bodies
    log_format detailed '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $body_bytes_sent '
                       '"$http_referer" "$http_user_agent" '
                       'Request-Body: "$request_body" '
                       'Content-Type: "$http_content_type" '
                       'Duration: $request_time s';
}

Sigma Detection Rule

Here’s a Sigma rule to detect exploitation attempts:

title: N8N Workflow RCE Attempt
status: experimental
description: Detects attempts to inject JavaScript expressions into n8n workflow payloads
author: Security Team
references:
  - https://github.com/wioui/n8n-CVE-2025-68613-exploit
date: 2025-12-25
tags:
  - attack.execution
  - attack.t1059.007
logsource:
  category: webserver
  product: generic
detection:
  selection:
    cs-method: POST
    cs-uri-stem|endswith: /rest/workflows
  keywords:
    - "this.process.mainModule.require('child_process')"
    - ".execSync("
    - "={{ (function(){"
    - "toString() })()"
  condition: selection and all of keywords
falsepositives:
  - Security testing activities
  - Legitimate development work
level: high

Post-Exploitation Monitoring

Don’t stop at web request monitoring! Attackers who successfully exploit this vulnerability might:

• Establish reverse shells for persistent access
• Download and execute additional malicious payloads
• Run reconnaissance commands to map the environment

Correlate your web log detection with process creation monitoring for comprehensive coverage.

The Bigger Picture

This vulnerability is a perfect example of why expression evaluation features need extreme caution in application design. It’s not just about input validation - it’s about fundamental trust boundaries between user code and the application runtime.

Key Takeaways

1. Sandboxing is Critical: User-provided code must be properly isolated from system resources
2. Defense in Depth: Don’t rely on a single detection method
3. Context Matters: Understanding the escalation chain helps both attackers and defenders
4. Update Immediately: This vulnerability has been patched in versions 1.120.4, 1.121.1, and 1.122.0

Wrapping Up

CVE-2025-68613 serves as a stark reminder that even well-intentioned features can become security nightmares when not properly implemented. The ability to execute expressions in workflows is incredibly useful, but without proper sandboxing, it becomes a direct path to system compromise.

If you’re running n8n in your environment, make sure you’re on a patched version. And if you’re building similar systems, remember that user input should never have direct access to system-level functionality, no matter how convenient it might seem.

Stay safe out there, and happy hunting! 🔍

Want to learn more about security vulnerabilities? Check out my other writeups and follow me for more security content!