CVE-2025-68613: Critical Remote Code Execution in n8n – Technical Breakdown, Exploitation, and Defensive Strategy

In December 2025, a critical Remote Code Execution (RCE) vulnerability—CVE-2025-68613—was disclosed in n8n, a widely adopted open-source workflow automation platform.
With a CVSS score of 9.9, this vulnerability allows any authenticated user to execute arbitrary system commands on the underlying server.

The root cause lies in unsafe expression evaluation, where user-supplied workflow expressions are executed as JavaScript without sufficient sandboxing or isolation.

This flaw impacts self-hosted, enterprise internal, and cloud-managed n8n deployments and represents a high-impact risk in environments where automation platforms are trusted to integrate sensitive systems.

Why This Vulnerability Matters

n8n is not just another SaaS application—it often sits at the center of enterprise automation, connecting:

• ERP systems
• Finance and accounting tools
• Identity providers
• Cloud infrastructure
• Security platforms
• Internal databases

A successful compromise of n8n is effectively a control-plane breach.

With CVE-2025-68613, an attacker does not need to bypass authentication entirely—any valid user account is enough.

Affected Versions and Patch Status

Vulnerable versions

• n8n 0.211.0 → 1.120.3

Patched versions

• 1.120.4
• 1.121.1
• 1.122.0

👉 Immediate upgrade is mandatory. There are no reliable configuration-only mitigations.

Technical Root Cause Analysis

n8n Expression Evaluation Engine

n8n supports dynamic expressions using double curly braces:

{{ expression }}

These expressions are evaluated at runtime as JavaScript and are commonly used to:

• Transform data
• Reference variables
• Control workflow logic

The Core Security Flaw

The vulnerability arises because:

1. Expressions are evaluated as raw JavaScript
2. The execution context is not sandboxed
3. Node.js internal modules remain accessible
4. No effective boundary exists between “expression logic” and “runtime code”

This results in a classic expression injection leading to RCE.

Exploitation Mechanics (High-Level)

The exploit leverages JavaScript’s ability to:

• Define and immediately invoke anonymous functions
• Load Node.js modules
• Execute system commands

Key Module Abused

The attack relies on Node.js’s built-in:

child_process

This module allows command execution using functions such as:

• exec
• spawn
• execSync

Once accessed, the attacker gains OS-level command execution with n8n’s process privileges.

Attack Chain Summary

1. Attacker authenticates to n8n (low-privileged account is sufficient)
2. Creates or edits a workflow
3. Injects a malicious expression inside a workflow field
4. Expression evaluator executes attacker-controlled JavaScript
5. JavaScript loads child_process
6. Arbitrary system commands are executed
7. Attacker can:
   • Read/write files
   • Establish reverse shells
   • Download malware
   • Pivot inside the network

This is not theoretical—the vulnerability is trivially exploitable via the UI.

Risk Scenarios in Real Environments

Enterprise Automation Platforms

• Lateral movement from automation engine into ERP or finance systems
• Credential harvesting from environment variables
• Abuse of API tokens stored in workflows

Internal DevOps & IT Automation

• Infrastructure compromise
• Cloud credentials exposure
• CI/CD pipeline poisoning

Managed Automation Services

• Multi-tenant risk if isolation is weak
• Data leakage across workflows

Detection Challenges

Native Logging Limitations

n8n does not provide:

• Granular expression execution logs
• Command execution telemetry
• Per-workflow security audit trails

As a result, native detection is insufficient.

Recommended Detection Strategy

1. Reverse Proxy Inspection (Critical)

Deploy n8n behind a reverse proxy (NGINX, Traefik, HAProxy) and log:

• Request bodies
• Workflow creation/modification requests

Focus on:

• POST /rest/workflows
• Suspicious JavaScript keywords
• Excessive curly brace nesting
• Runtime function construction patterns

2. SIEM Correlation

Correlate:

• Web request logs
• Process creation events
• Network egress activity

Indicators include:

• node spawning shell processes
• Unexpected outbound connections
• Command execution patterns shortly after workflow edits

3. Endpoint & Runtime Monitoring

Monitor for:

• node → bash, sh, curl, wget
• File system access outside expected paths
• Execution of reconnaissance commands (id, whoami, uname)

Mitigation & Hardening Guidance

Mandatory Actions

• ✅ Upgrade to a patched version immediately
• ✅ Rotate all secrets used in workflows
• ✅ Audit existing workflows for suspicious expressions

Strongly Recommended

• Restrict user access (least privilege)
• Place n8n behind a WAF or API gateway
• Run n8n with non-privileged OS accounts
• Isolate n8n in a hardened container or VM
• Monitor outbound traffic from the n8n host

Strategic Lessons for Security & Engineering Teams

This vulnerability highlights a recurring class of design failures:

• User-controlled code execution
• Expression engines without sandboxing
• Implicit trust in “authenticated users”

Modern automation platforms must treat expressions as untrusted input, not “helper logic”.

From a purple-team perspective, CVE-2025-68613 is an excellent case study in:

• Injection vulnerabilities beyond SQL
• Runtime trust boundary failures
• Detection gaps in low-code / no-code platforms

Final Thoughts

CVE-2025-68613 is not just an n8n issue—it is a warning signal for the entire automation ecosystem.

As organizations increasingly adopt:

• Low-code platforms
• Workflow automation
• AI-driven orchestration

…the attack surface shifts from infrastructure to logic engines.

Security teams must evolve detection and threat modeling accordingly.

Patch immediately. Monitor aggressively. Trust no expression engine by default.