CVE-2025-68613: Critical RCE in n8n Workflow Automation Platform

On December 19, 2025, a critical remote code execution vulnerability was disclosed in n8n, one of the most popular open-source workflow automation platforms. The flaw, tracked as CVE-2025-68613, carries a devastating CVSS score of 9.9 out of 10, indicating near-maximum severity. This is not a vulnerability to ignore or delay on. If you run n8n in your infrastructure, you need to act immediately.

The stakes are enormous. More than 103,000 potentially vulnerable n8n instances are currently accessible on the internet. These are real deployments in real organizations, connected to critical business processes, sensitive APIs, and confidential data repositories. A successful exploit of this vulnerability doesn't just compromise an application. It hands attackers complete control of the system running n8n and everything it's connected to.

What Exactly Is CVE-2025-68613?

The vulnerability lies in how n8n handles workflow expressions. When you build a workflow in n8n, you often use expressions wrapped in double curly braces {{}} to manipulate data, access variables, and perform calculations. These expressions are evaluated at runtime. The problem is that n8n's expression evaluation engine was not properly sandboxed from the underlying Node.js runtime environment.

Under certain conditions, authenticated users can craft specially designed expressions that break out of the sandbox and gain access to the Node.js global this object. From there, an attacker can require dangerous modules like child_process, which allows execution of arbitrary system commands. This isn't a complex multi-step exploit requiring deep expertise. It's a relatively straightforward sandbox escape that any authenticated user with workflow creation permissions can leverage.

The core issue stems from insufficient isolation in the execution context. n8n's developers created a sandbox to contain expressions, but the implementation had a critical flaw that allowed expressions to access global scope and system-level capabilities they shouldn't have access to.

Which n8n Versions Are Affected?

The vulnerability affects n8n versions starting from version 0.211.0 and extends through multiple release branches up to but not including:

• Version 1.120.4
• Version 1.121.1
• Version 1.122.0

If your n8n instance is running any version in the range 0.211.0 through 1.119.x, it is vulnerable. The n8n team strongly recommends upgrading to version 1.122.0 or later, which introduces additional safeguards to properly restrict expression evaluation and prevent this type of sandbox escape.

If you're on an older release branch and cannot immediately jump to 1.122.0, the following minimum versions include backported fixes:

• 1.120.4 or later (if you're on the 1.120.x branch)
• 1.121.1 or later (if you're on the 1.121.x branch)

However, these are band-aid solutions. The recommendation is to consolidate on version 1.122.0 or newer as soon as feasible.

What Happens When This Vulnerability Gets Exploited?

Understanding the real-world impact of this vulnerability is crucial. This isn't a theoretical risk. An attacker with a valid n8n account can do serious damage.

Arbitrary Command Execution

An attacker can execute system commands with the privileges of the user running n8n. On many deployments, that means commands run with the privileges of the container or system user, potentially with broad access to the underlying infrastructure. Attackers can navigate the filesystem, create files, modify system configuration, install persistence mechanisms, or establish reverse shells for continued access.

Stealing Secrets and Credentials

n8n workflows typically interact with external APIs, databases, and cloud services. Credentials for these services are often stored as environment variables or in n8n's secure storage. A successful exploit allows attackers to extract these secrets. Imagine API keys for your cloud providers, database passwords, SaaS service credentials, encryption keys, and authentication tokens all exposed to a determined attacker. From there, lateral movement into your broader infrastructure becomes trivial.

Full Instance Compromise

Because n8n is designed to be a central hub connecting multiple services and systems, compromising it often opens doors to everything it's connected to. Attackers can read, modify, or delete workflows. They can inject malicious logic into workflows that should have been trusted. They can exfiltrate data that flows through automations. In multi-tenant deployments, they might gain access to other users' workflows and credentials.

System-Level Operations

The attacker isn't limited to what n8n does directly. They can execute arbitrary OS-level operations, potentially leading to:

• Installation of malware or persistence mechanisms
• Denial of service attacks affecting the host
• Privilege escalation attempts to gain root access
• Network reconnaissance and lateral movement into internal networks

The Attack Surface: 103,000+ Exposed Instances

According to Censys data collected at the time of disclosure, more than 103,000 potentially vulnerable n8n instances are currently reachable over the internet. The geographical distribution shows significant concentrations in the United States, Germany, France, Brazil, and Singapore, but vulnerable instances are scattered across the globe.

This number itself is alarming, but what makes it worse is that many of these instances likely run in environments with:

• Internet accessibility without strong authentication
• Shared access where multiple users or teams can create workflows
• Integration with critical internal systems, databases, and APIs
• Weak access controls and limited workflow approval processes

For an attacker, this represents an enormous opportunity. They don't need to target a specific organization. They can scan the internet, find vulnerable n8n instances, attempt to gain access or register accounts, and systematically compromise targets.

Exploitation Requirements and Likelihood

One detail that provides some protection is that exploitation requires authentication. An attacker cannot exploit this vulnerability against an n8n instance they have zero access to. However, this does not mean you're safe if your n8n instance requires login. Consider your authentication practices:

If your n8n instance has open registration, an attacker can create their own account and immediately exploit the vulnerability. If you use weak password policies or default credentials, attackers can brute force or guess their way in. If you use single sign-on but your SSO provider allows broad access, attackers inside your organization could exploit this. If you've shared login credentials across teams or documented credentials in accessible places, an attacker could find them.

Public proof-of-concept code has already been released, which dramatically lowers the technical barrier to exploitation. An attacker no longer needs deep understanding of n8n's internals or the sandbox escape mechanics. They can simply copy publicly available exploit code and adapt it for their target.

The vulnerability is not yet widely exploited in the wild based on available threat intelligence, but that's a window that won't stay open forever. The longer organizations take to patch, the higher the risk that organized threat actors will begin systematizing attacks.

Emergency Remediation Steps

If you run n8n, here's what you should do immediately:

Step 1: Assess Your Risk Exposure

Determine whether your n8n instances are internet-facing or accessible from untrusted networks. Check your current n8n version. Inventory which systems and services your n8n instances connect to and what credentials they hold. This assessment helps you understand the true impact of a potential breach.

Step 2: Patch Immediately

If you're running Docker, pull the latest image and deploy it:

docker pull n8nio/n8n:latest
docker-compose up -d

If you're using npm or running from source:

npm install -g n8n@latest

This is not a routine maintenance update. Treat this as an emergency security patch that takes priority over ongoing deployments or maintenance windows. Test briefly in a dev environment if you must, but move to production as quickly as safely possible.

Step 3: Temporary Mitigations While Patching

If you cannot patch immediately (though you should try very hard to), implement these interim measures:

Restrict workflow creation and editing permissions to a small group of trusted users. Remove access from regular users and teams if possible. This dramatically reduces the attack surface since exploitation requires the ability to create or edit workflows.

Deploy n8n in a hardened environment with minimal operating system privileges. Run it in a container with restricted capabilities. Limit outbound network access. Use operating system-level access controls to prevent the n8n process from accessing sensitive files or executing arbitrary binaries.

Disable public registration if it's enabled. Require explicit account provisioning by administrators.

Rotate all credentials that n8n has access to. If a compromise has already occurred, you want those credentials invalidated regardless. Assume any API keys or passwords that n8n stores are potentially compromised until proven otherwise.

Monitor n8n logs and system logs for suspicious activity. Look for unusual expression evaluations, command execution attempts, or access to files that shouldn't be touched by n8n.

Step 4: Post-Patch Review

After patching, conduct a security review of your n8n deployment. Audit who has workflow creation and editing permissions. Review existing workflows to understand what data flows through them and what systems they access. Consider implementing code review processes for workflow changes, similar to what you'd do for application code. Review access logs to detect any suspicious activity that might indicate prior exploitation attempts.

Broader Context: n8n Security and Workflow Automation Risks

This vulnerability is not an isolated incident. Workflow automation platforms sit at a dangerous intersection of convenience and security risk. They need to manipulate data, access system capabilities, and integrate with external services. This inherent functionality creates a large attack surface. Other recent n8n vulnerabilities show this is a systemic concern:

✅ CVE-2025-65964 is a separate vulnerability involving the Git node where workflow actions could influence Git configuration and cause hook execution, potentially enabling RCE.

✅ CVE-2025-57749 is a symlink traversal vulnerability in n8n's file read/write operations.

✅ These multiple vulnerabilities in a short timeframe suggest that n8n's security posture needs strengthening at a fundamental level. While the n8n team is actively patching issues, organizations relying on n8n should implement additional defensive measures:

✅ Implement role-based access control strictly. Not everyone needs to create workflows.

✅ Use network segmentation to isolate your n8n instance from sensitive systems.

✅ Consider running n8n in a dedicated environment with minimal access to production databases and APIs.

✅ Implement monitoring and alerting for suspicious workflow behavior.

✅ Conduct periodic security audits of your n8n deployment and connected systems.

✅ Evaluate n8n's security roadmap and updates before integrating it deeply into critical infrastructure.

Conclusion

CVE-2025-68613 is a serious vulnerability that demands immediate attention from anyone running n8n. With a CVSS score of 9.9, over 103,000 exposed instances online, and publicly available proof-of-concept code, the risk window is narrow.

The fix is straightforward: update to n8n version 1.122.0 or later as soon as possible. While temporary mitigations exist, they're not complete solutions. Patching is the only way to truly eliminate this risk.