A critical vulnerability (CVE-2026-1470, CVSS 9.9) was disclosed on January 27, 2026 affecting n8n, the popular open-source workflow automation platform. The flaw allows authenticated users to bypass the JavaScript sandbox and execute arbitrary commands on the server. Immediate patching is required for all self-hosted n8n deployments.
What is n8n?
n8n is a workflow automation tool-similar to Zapier or Power Automate, that lets organizations connect different services and automate tasks. Think of it as a central hub that holds the keys to your infrastructure: API tokens, database credentials, cloud provider secrets, and OAuth tokens for every service it integrates with.
This is why a vulnerability in n8n is particularly dangerous. Compromising n8n doesn’t just give attackers one server, it potentially gives them access to everything n8n connects to.
The Vulnerability Explained
The vulnerability was discovered by security researcher Natan Nehorai from JFrog Security Research. Here’s what happens:
When building workflows in n8n, users can write JavaScript expressions inside double curly braces, like {{ $json.email }}. To prevent users from running dangerous code, n8n implements a sandbox. This sandbox parses the JavaScript into a structure called an Abstract Syntax Tree (AST), essentially breaking code down into labeled components, and blocks anything that looks dangerous.
One thing the sandbox blocks is access to .constructor. Why? Because in JavaScript, if you can reach the Function constructor, you can create and run any code you want. The sandbox sees .constructor and stops it.
Here’s the bypass: the sandbox only blocks constructor when it appears as a property access (like obj.constructor). It doesn’t block constructor when it appears as a standalone word.
JavaScript has a deprecated feature called the with statement that changes how variable names are looked up. By using with(function(){}), an attacker can make the standalone word constructor resolve to the Function constructor, bypassing the sandbox entirely and achieving full code execution on the server.
Who is Affected?
The following n8n versions are vulnerable:
| Branch | Vulnerable | Patched |
|---|---|---|
| 1.x | All versions before 1.123.17 | 1.123.17+ |
| 2.4.x | All versions before 2.4.5 | 2.4.5+ |
| 2.5.x | All versions before 2.5.1 | 2.5.1+ |
n8n Cloud users are already protected, patches were applied server-side. Only self-hosted deployments need to take action.
Note: JFrog also discovered a related vulnerability (CVE-2026-0863, CVSS 8.5) in n8n’s Python Code Node. That flaw was patched in versions 1.123.14, 2.3.5, and 2.4.2. Make sure you’ve addressed both.
What You Need to Know
Exploitation requires authentication-specifically, the ability to create or edit workflows. This isn’t unauthenticated RCE, but in many organizations, multiple team members have workflow access, and some deployments are internet-facing.
At the time of writing, no active exploitation has been reported and no weaponized proof-of-concept has been publicly released, though JFrog has published technical details. Given the severity, this could change quickly.
Why This Matters Beyond n8n
This vulnerability highlights a fundamental challenge with JavaScript sandboxing. The language wasn’t designed with isolation in mind, and there are many creative paths to reach dangerous functionality-prototype chains, computed property access, scoping tricks like with. If your organization runs any system that evaluates user-supplied JavaScript (templating engines, plugin systems, low-code platforms), this class of vulnerability deserves attention in your threat model.
Remediation
Upgrade to patched versions immediately: n8n 1.123.17+, 2.4.5+, or 2.5.1+.
If you cannot patch immediately, limit workflow editing permissions to trusted users only and ensure your n8n instance is not exposed to the internet.
How Can Orca Help?
Orca enables customers to quickly identify assets running vulnerable n8n versions, understand their exposure in context-including internet accessibility, runtime reachability, and asset criticality, and prioritize remediation based on real risk rather than CVSS alone. Orca’s platform highlights affected assets directly in the News Item view, helping security teams focus on the most critical remediation paths first.
