Critical n8n Flaw Lets Attackers Execute Code on 100,000+ Instances

A critical vulnerability in n8n, the popular open-source workflow automation platform, allows authenticated attackers to execute arbitrary code on the underlying server. With over 103,000 potentially vulnerable instances exposed to the internet and public exploit code now circulating, organizations running n8n should treat this as an emergency.

TL;DR

• What happened: Expression injection flaw in n8n allows authenticated users to execute arbitrary system commands
• Who's affected: n8n versions 0.211.0 through 1.120.4 (103,000+ internet-exposed instances per Censys)
• Severity: Critical (CVSS 9.9)
• Action required: Upgrade to n8n version 1.122.0 or later immediately

How Does CVE-2025-68613 Work?

The vulnerability exists in how n8n evaluates user-supplied expressions—those wrapped in double curly braces {{ }}. While these expressions are meant to manipulate workflow data, the underlying Node.js execution environment lacks proper sandboxing.

Attackers can bypass restrictions by accessing the global this context within an expression. From there, they can reach process.mainModule.require, which opens the door to loading Node.js modules like child_process. Once that's accessible, executing shell commands becomes trivial.

The flaw requires authentication, but that's cold comfort. Many n8n deployments allow self-registration or use weak credentials. Published proof-of-concept code lowers the bar further—anyone with workflow creation privileges can now attempt exploitation.

What Can Attackers Do?

Successful exploitation grants attackers the privileges of the n8n process. In practical terms:

• Execute arbitrary commands on the host system
• Read and write any file the process can access, including configuration files, API keys, and database credentials
• Pivot to connected systems—databases, CI/CD pipelines, internal APIs, cloud infrastructure
• Install persistent backdoors

For organizations using n8n to orchestrate sensitive business processes, compromise of this system could cascade into broader network intrusion.

Scale of Exposure

According to Censys, 103,476 potentially vulnerable n8n instances were internet-accessible as of December 22. The largest concentrations appear in:

• United States
• Germany
• France
• Brazil
• Singapore

Self-hosted instances behind corporate firewalls may not appear in internet scans but remain vulnerable if any authenticated user turns malicious—or if credentials leak.

Patch Information

n8n addressed the vulnerability in version 1.122.0, released December 20. Backported fixes are also available in versions 1.120.4 and 1.121.1 for organizations that can't immediately jump to the latest release.

If patching isn't immediately possible, the n8n team recommends:

1. Restrict workflow creation and editing to fully trusted administrators only
2. Disable public registration if enabled
3. Run n8n with minimal operating system privileges
4. Isolate the n8n host from sensitive network segments

These mitigations reduce risk but don't eliminate it. Patching remains the only complete fix.

Important update: A second critical n8n vulnerability (CVE-2026-21858) was disclosed shortly after this one—and it requires no authentication at all. Organizations patching CVE-2025-68613 should address both vulnerabilities.

Why This Matters

n8n has grown rapidly as organizations seek alternatives to expensive commercial automation platforms. Its flexibility—connecting hundreds of services via API—makes it valuable for everything from marketing automation to DevOps pipelines.

That same flexibility creates risk. A compromised n8n instance doesn't just give attackers a foothold on one server; it potentially hands them credentials and access to every service the platform integrates with. OAuth tokens, API keys, database connection strings—all may be extractable from a compromised deployment.

Frequently Asked Questions

Is my organization affected by CVE-2025-68613?

If you're running n8n versions 0.211.0 through 1.120.4, you're vulnerable. Check your version in the n8n settings or by running n8n --version from the command line. Cloud-hosted n8n instances managed by n8n GmbH have already been patched.

What should I do first?

Upgrade to version 1.122.0. If you can't patch immediately, restrict workflow editing permissions to only the most trusted users and audit recent workflow changes for suspicious expression syntax.

Are there indicators of compromise I can check?

Look for workflows containing expressions that reference process, require, child_process, or mainModule. Unusual outbound connections from your n8n host or unexpected files in the n8n working directory may also indicate compromise.