Two Critical n8n Vulnerabilities: Sandbox Escapes Leading to Full Remote Code Execution

n8n Vulnerabilities: Sandbox Escapes Leading to RCE

Overview

A sandbox is only as strong as its weakest runtime.

Workflow automation platforms promise leverage. They compress weeks of engineering into visual logic, connect systems that were never meant to talk, and quietly become critical infrastructure.

n8n does this extremely well. That is exactly why today's disclosure matters.

Security researchers at JFrog have uncovered two high-severity vulnerabilities in n8n that allow authenticated users to escape sandboxed execution environments and execute arbitrary code on the host system. These are not edge cases or theoretical bypasses. They are reliable sandbox escapes that collapse one of n8n's core security assumptions.

If n8n is running in your production environment, this is not optional reading. It is an incident waiting to happen.

This document breaks down what went wrong, how the exploits work at a technical level, why the impact is serious, and what defenders should do immediately.

Why n8n Is a High-Value Target

n8n is a fair-code workflow automation platform that enables users to chain APIs, services, and logic using a node-based visual interface. It is often compared to Zapier, but with two key differences: it is self-hosted, and it allows custom code execution.

n8n is widely used for:

• AI and LLM orchestration pipelines
• CRM and sales automation
• Internal DevOps tooling
• Data synchronization and enrichment
• Glue logic between cloud services

This flexibility is also its biggest risk surface.

n8n allows users to execute:

• JavaScript expressions embedded directly into workflows
• JavaScript and Python Code nodes with access to runtime data

To mitigate risk, n8n relies on sandboxing, AST-based validation, and deny lists to restrict dangerous language features.

According to JFrog, those sandboxes can be bypassed.

With more than 264,000 publicly exposed n8n instances observable via ZoomEye, exploitation at scale is a realistic concern.

A Familiar Pattern: Sandboxes Fail Quietly

This disclosure follows shortly after Ni8mare (CVE-2026–21858), an unauthenticated remote code execution vulnerability that impacted close to 100,000 servers.

While today's vulnerabilities require authentication, they are arguably more dangerous in real environments. Authenticated access is often easier to obtain than defenders assume, especially in multi-user automation platforms where permissions are loosely enforced.

Both vulnerabilities bypass core security controls, resulting in direct execution on the n8n host.

Vulnerability Analysis

CVE-2026–1470: JavaScript Expression Sandbox Escape

CVSS Score: 9.9 (Critical)

What Is Vulnerable

n8n evaluates JavaScript expressions inside workflows using a custom sandbox designed to prevent access to dangerous globals such as:

• Function
• constructor
• process

The sandbox uses multiple defensive layers, including AST parsing and regex-based checks.

Why the Sandbox Fails

The sanitizer blocks .constructor when accessed as a member expression, but it fails to account for situations where constructor appears as a standalone identifier.

The deprecated but still valid JavaScript with statement allows attackers to manipulate scope resolution in a way that defeats this protection.

Proof of Concept

{{ (function(){
  var constructor = 'gotcha';
  with(function(){}) {
    return constructor("return 1337")()
  }
})() }}

This expression resolves constructor to Function.prototype.constructor, effectively restoring access to the Function object.

From there, full code execution is trivial:

Function(
  "return process.mainModule.require('child_process')" +
  ".execSync('id').toString()"
)()

At this point, the attacker has arbitrary command execution on the n8n host.

Affected Versions

All versions prior to:

• 1.123.17
• 2.4.5
• 2.5.1

CVE-2026–0863: Python Code Node Sandbox Escape

CVSS Score: 8.5 (High)

Scope

This vulnerability affects Python Code nodes running in Internal execution mode.

Why the Sandbox Fails

The Python sandbox relies on:

• A deny list of dangerous builtins
• A restricted global namespace
• Execution via exec()

These controls are brittle against Python's introspection features.

Key weaknesses exploited include:

• Frame introspection leaking restricted objects
• Python 3.10 introducing the .obj attribute on AttributeError
• Abuse of string formatting to bypass attribute filters
• Dynamic reconstruction of __import__

Result

Attackers can recover access to restricted builtins, import system modules like os, and execute arbitrary commands with host privileges.

Example payloads demonstrated calls such as:

os.uname()

This confirms direct access to the underlying operating system.

Affected Versions

All versions prior to:

• 1.123.14
• 2.3.5
• 2.4.2

This vulnerability applies only to Internal execution mode, which is strongly discouraged for production use.

Real-World Impact

n8n instances often have access to:

• API keys and OAuth tokens
• Cloud credentials
• Internal service endpoints
• LLM APIs
• Webhooks and automation secrets

A successful exploit enables:

• Full host compromise
• Credential harvesting
• Lateral movement
• Workflow manipulation
• Supply-chain style attacks through downstream integrations

JFrog researchers described this access as a skeleton key to automation infrastructure, and that assessment is accurate.

Security researchers are already sharing detection templates, and public exploit tooling is likely to follow.

Mitigation and Defensive Guidance

1. Patch Immediately
   
   Upgrade to fixed versions without delay. If you are running n8n in Docker, pull the latest images. npm-based deployments should update as soon as possible.

2. Disable Python Internal Execution Mode
   
   Use External execution mode with Docker isolation. Internal mode should not be used in production environments under any circumstances.

3. Harden Your Deployment

   • Restrict workflow creation and editing to trusted users
   • Run n8n in containers with seccomp and AppArmor profiles
   • Remove unnecessary host filesystem access
   • Monitor logs for unexpected subprocess execution
   • Audit existing workflows for suspicious expressions or Code nodes

4. Reduce External Exposure

   • Do not expose n8n directly to the internet
   • Identify exposed instances using queries like app="n8n"
   • Enforce VPN or zero-trust access controls

The Broader Lesson

Sandboxing dynamic, high-level languages is a continuous arms race.

JavaScript and Python evolve rapidly. Runtime features introduced for debugging, ergonomics, or developer convenience frequently become attack primitives years later.

As JFrog researcher Nathan Nehorai noted, subtle runtime behaviors can quietly invalidate long-held security assumptions.

If your platform executes user-supplied code, assume sandbox escapes will eventually happen.

Design accordingly.

Closing Thoughts

n8n remains a powerful automation platform, but power demands discipline.

Patch immediately. Revisit your trust boundaries. Treat workflow authors as privileged users. And remember that convenience often hides complexity until it fails catastrophically.

If you work in automation, DevSecOps, or platform security, this disclosure is worth a permanent bookmark.

Stay sharp.

Sources

• JFrog Research
• NVD
• The Hacker News
• Public X discussions

License

This document is provided for informational purposes only. For more details, refer to the original JFrog disclosure.