TL;DR
If you use n8n (the workflow automation tool), stop what you are doing and check your version immediately.
A critical vulnerability, tracked as CVE-2025-68613 (CVSS 9.9/10), has been discovered that allows authenticated users to execute arbitrary code on the host server. This is a Remote Code Execution (RCE) flaw rooted in the workflow expression system.
The Bottom Line:
- What: Authenticated users can break out of the Javascript sandbox in n8n workflows.
- Impact: Full server takeover, access to all API keys/credentials stored in n8n, and lateral movement into connected internal networks.
- Affected Versions: Versions starting from 0.211.0 up to < 1.120.4, 1.121.1, and 1.122.0.
- The Fix: Update to version 1.122.0 or later immediately.
When Automation Becomes the Attack Vector
In late December 2025, the cybersecurity community was rattled by the disclosure of CVE-2025-68613, a catastrophic security flaw in n8n, one of the world’s most popular open-source workflow automation platforms. With over 100,000 instances estimated to be exposed to the internet, n8n has become a critical backbone for companies automating everything from marketing emails to DevOps pipelines.
However, the very feature that makes n8n powerful—its ability to execute custom Javascript expressions—has become its Achilles’ heel.
This is not just another bug. This is a sandbox escape. It fundamentally breaks the trust model of the application, turning a helpful automation bot into a potential remote access trojan (RAT) for attackers.
In this exhaustive guide, we will dissect exactly how this vulnerability works, why it slipped through the cracks, and how you can secure your infrastructure against the rising tide of Low-Code/No-Code (LCNC) security threats.
Technical Deep Dive: Anatomy of CVE-2025-68613
To understand the severity of this vulnerability, we must look under the hood of n8n’s architecture.
The “Expression” Engine
n8n allows users to use data from previous nodes in their workflows. This is often done using “Expressions,” which are snippets of JavaScript wrapped in double curly braces, like {{ $json.myVariable }}.
To provide this functionality, n8n evaluates these strings server-side using Node.js. Ideally, this evaluation should happen in a Sandbox—a restricted environment that allows math and basic logic but forbids access to the underlying operating system (OS).
Sandbox Escape
The vulnerability arises because the isolation mechanism used for these expressions was insufficient. In Node.js, creating a truly secure sandbox is notoriously difficult.
Attackers found that they could access the global execution context from within an expression. By crafting a specific Javascript payload, an authenticated user could access the this keyword in a way that exposed the main Node.js process.
Once an attacker has access to the process object (this.process), they can:
- Import Modules: Load the
child_processmodule, which is used to run OS commands. - Execute Commands: Run shell commands like
cat /etc/passwd,env(to steal secrets), or install reverse shells. - Bypass Authentication: Since the code runs with the privileges of the n8n service, it bypasses standard application-level checks.
Why “Authenticated” Doesn’t Mean “Safe”
You might read “Authenticated User Required” and think, “Oh, I’m safe, I don’t give accounts to strangers.” This is a dangerous misconception.
- The Insider Threat: In large organizations, dozens of employees may have access to create workflows. One disgruntled employee can wipe the server.
- Account Takeover: If a single employee’s n8n credentials are phished (or reused from a breach), the attacker instantly gains RCE capability.
- Shared Accounts: Many teams share a single “admin” login, making audit trails impossible and increasing the attack surface.
Impact Analysis: The “Keys to the Kingdom” Scenario
Why is n8n a higher-value target than a standard web server? Credentials.
n8n is designed to talk to other services. To do this, it stores:
- AWS Secret Keys
- Stripe API Tokens
- Slack Webhooks
- Database Connection Strings (Postgres, MySQL, MongoDB)
- CRM Login Details
Scenario A: The Data Heist
An attacker exploits CVE-2025-68613 to run a command that prints all environment variables (env). They immediately harvest your AWS keys and database passwords. Within minutes, they are exfiltrating customer data from your production database, bypassing your firewall because they effectively have “legitimate” credentials.
Scenario B: Lateral Movement
n8n often sits inside a private network (VPC) to access internal APIs. By compromising the n8n container, the attacker gains a foothold inside your private network. They can now scan for other vulnerable internal services that are not exposed to the public internet, using n8n as a “jump box.”
Scenario C: Supply Chain Poisoning
Imagine an attacker modifies a “Release Pipeline” workflow. They could inject malicious code into your company’s software builds, affecting your customers. This turns your automation tool into a weapon against your own supply chain.
Remediation & Mitigation Strategy
If you are running n8n, you are in a race against time. Public Proof-of-Concept (PoC) exploits are already circulating on GitHub and security forums.
1. The Golden Standard: UPGRADE NOW
The n8n team has released patches. You must upgrade to one of the following versions (or higher) immediately:
- v1.122.0 (Recommended)
- v1.121.1
- v1.120.4
For Docker Users:
docker pull n8n/n8n:latest
docker stop n8n
docker rm n8n
# ... restart with new image2. Immediate Mitigation (If You Can’t Patch)
If you are stuck on an old version due to breaking changes, you must isolate the instance:
- Network Isolation: Ensure n8n is NOT accessible from the public internet. Put it behind a VPN or a strict IP whitelist.
- Restrict Permissions: Remove “Workflow Create/Edit” permissions from as many users as possible.
- Hardening: Ensure the n8n container runs as a non-root user. This limits the damage if code is executed (the attacker won’t have root privileges on the OS).
3. Long-Term Defense: The “Zero Trust” Approach to Automation
CVE-2025-68613 is a wake-up call. We must treat automation platforms as critical infrastructure.
- Isolate Environments: Do not run n8n on the same server as your production database.
- Secrets Management: Use external secrets managers (like HashiCorp Vault or AWS Secrets Manager) rather than storing hardcoded keys in n8n nodes.
- Audit Logging: Enable verbose logging and ship logs to a SIEM. Look for suspicious keywords in workflow executions like
child_process,exec, orspawn.
The Future of Low-Code Security in 2026
As we move deeper into 2026, the “Low-Code/No-Code” (LCNC) revolution is hitting a security wall. Tools like n8n, Zapier, and Make are democratizing development, but they are also bypassing traditional Software Development Life Cycle (SDLC) security checks.
Traditional code goes through peer review, SAST/DAST scanning, and QA. An n8n workflow created by a marketing manager often goes straight to production.
CVE-2025-68613 is likely the first of many. As these platforms grow more complex, adding features like “AI Agents” and “Python Scripting,” the attack surface expands. Security teams must adapt by integrating these tools into their vulnerability management programs, rather than treating them as harmless “productivity apps.”
Frequently Asked Questions (FAQs)
Is my hosted n8n (Cloud) account vulnerable?
If you use the official n8n Cloud offering, the team has likely already patched your instance. However, you should check your instance version in the bottom left corner of the dashboard to confirm you are on v1.122.0+.
Can this be exploited without a username/password?
No. This is an authenticated vulnerability. The attacker needs to be logged in. However, if you have “Open Signups” enabled (a common misconfiguration), an attacker can simply create an account and then exploit the server.
Does this affect the Desktop version of n8n?
Yes, the vulnerability exists in the core codebase. If you run the desktop app and it is accessible via a network (or if malware on your PC interacts with it), it is vulnerable. Update the desktop application immediately.
How do I check if I’ve been compromised?
Check your n8n execution logs for workflows you don’t recognize. Check your server’s bash_history for unusual commands. Look for unknown outbound network connections from the n8n process. Rotate ALL credentials (API keys, DB passwords) stored in n8n as a precaution.
Disclaimer: This article is for educational and defensive purposes only. Do not attempt to exploit vulnerabilities on systems you do not own or have explicit permission to test.
