On February 5th, 2026, the n8n project disclosed 12 security vulnerabilities in a single coordinated release. Five were rated critical. The most severe - CVE-2026-25049 - allows any authenticated user to escape the expression sandbox and execute arbitrary system commands on the host.

The vulnerability exists because of a fundamental mismatch: TypeScript enforces type safety at compile time, but attackers craft payloads at runtime. The sanitization check assumes string input. The attacker sends an object. The sandbox believes it’s safe. The server executes whatever the attacker wants.

This matters far beyond n8n. Workflow automation platforms - n8n, Make (Integromat), Zapier, Microsoft Power Automate, Tray.io - are the invisible agentic infrastructure running behind millions of business processes. They execute multi-step workflows, connect to external APIs, read and write data, and run code. They’re AI agents without the LLM branding.

And their security model is built on sandboxes that don’t actually contain anything.

The Disclosure

The vulnerability chain is elegant in its simplicity. n8n uses a custom expression language that allows users to reference data from previous workflow steps. To prevent code injection, expressions are sanitized before evaluation. The sanitization check verifies that inputs are strings.

The problem: TypeScript’s compile-time type system doesn’t enforce runtime behavior. When an attacker crafts a malicious expression using JavaScript destructuring syntax, they pass a non-string value that the sanitizer doesn’t recognize as dangerous.

The Full Vulnerability Set

The sandbox escape is just the headline. The full disclosure includes 12 vulnerabilities across multiple attack surfaces:

Six more vulnerabilities (CVE-2026-21893, CVE-2026-25051, CVE-2026-25054, CVE-2026-25055, CVE-2026-25631, CVE-2025-61917) cover additional attack vectors: admin command injection, stored XSS leading to session hijacking, path traversal to remote systems, credential exfiltration, and buffer exposure.

Workflow Automation Is Agentic Infrastructure

Here’s what the security industry needs to understand: workflow automation platforms ARE agentic AI infrastructure. They just don’t market themselves that way.

The only difference is the control plane. AI agents use natural language planning. Workflow platforms use visual node editors. The execution model - autonomous, tool-using, data-accessing, code-running - is identical.

This means workflow automation vulnerabilities map directly to the OWASP Agentic Top 10 (2026):

ASI02 (Tool Misuse): The Git node, Merge node, and SSH node are legitimate tools being misused for command injection, file writes, and path traversal. The tools work exactly as designed - they’re just being invoked with malicious parameters.

ASI04 (Supply Chain): Git repositories with malicious hooks, external packages loaded at runtime, and community-contributed nodes all represent supply chain risks. The Git Hook RCE (CVE-2025-62726) is a textbook supply chain attack.

ASI05 (Unexpected Code Execution): Five of the twelve CVEs result in arbitrary code execution. The expression sandbox, Python sandbox, and file write capabilities all become RCE vectors when their containment fails.

ASI08 (Cascading Failures): A single compromised workflow can cascade across connected systems. The TOCTOU vulnerability (CVE-2026-25052) demonstrates how a race condition in one node can lead to account takeover across the entire instance.

The Webhook Amplification Problem

The vulnerabilities become significantly more dangerous when combined with n8n’s webhook feature. SecureLayer7’s analysis describes the attack chain:

1. Attacker creates a workflow with a publicly accessible webhook (no authentication required)
2. Adds a node containing the sandbox escape payload
3. Activates the workflow, exposing the webhook to the internet
4. Anyone can now trigger the webhook and execute commands on the n8n host

This transforms CVE-2026-25049 from “authenticated user can compromise the server” to “anyone on the internet can compromise the server.” The authentication requirement vanishes when the attack payload is embedded in a workflow that exposes a public endpoint.

Why Sandboxes Keep Failing

The pattern repeats across every workflow automation and code execution platform:

1. Platform adds code execution capability (expressions, scripts, custom functions)
2. Platform implements sandbox to contain execution
3. Researchers find sandbox escape
4. Platform patches
5. Researchers find bypass
6. Goto 4

The fundamental problem is that sandboxes are fighting JavaScript’s design. JavaScript was built for flexibility, not containment. Every creative use of prototypes, destructuring, proxies, or async behavior is a potential escape hatch.

As Endor Labs explained: “The vulnerability arises from a mismatch between TypeScript’s compile-time type system and JavaScript’s runtime behavior. TypeScript cannot enforce these type checks on runtime attacker-produced values.”

This isn’t an n8n-specific problem. It’s a fundamental limitation of trying to build secure sandboxes in a language designed to be dynamically typed and maximally flexible. The sandbox is always playing defense against a language that wants to let you do anything.

What This Means for Agentic AI

The n8n disclosure is a preview of what’s coming for AI agent platforms. Every AI framework that allows tool execution, code generation, or plugin loading faces the same architectural challenges:

1. Sandboxes are not security boundaries. They’re speed bumps. If your threat model assumes the sandbox will contain malicious execution, your threat model is wrong. Treat every code execution capability as a potential RCE.

2. Type safety doesn’t survive untrusted input. TypeScript, Rust’s type system, Python’s type hints - none of them protect against malicious input at runtime. Sanitization must happen at the value level, not the type level.

3. Webhooks transform internal vulnerabilities into external ones. Any platform that allows public endpoints to trigger automated workflows has an amplification problem. The authentication boundary becomes irrelevant when the attacker’s code runs inside an authenticated workflow.

4. Low-code doesn’t mean low-risk. “Vibe coding,” no-code automation, visual workflow builders - they all lower the barrier to creating powerful, connected, code-executing systems. They don’t lower the barrier to securing them. If anything, they raise it by abstracting away the security-relevant details.

Defending Workflow Automation

If your organization runs n8n, Make, Zapier, Power Automate, or any workflow automation platform, these are the immediate actions:

The Broader Lesson

The n8n disclosure isn’t really about n8n. It’s about the collision between two trends:

Trend 1: Automation is eating everything. Businesses want workflows that connect systems, process data, and take actions without human intervention. Workflow automation platforms deliver exactly this.

Trend 2: Attackers follow capabilities. When a platform can execute code, write files, make API calls, and trigger external systems, it becomes a high-value target. The same capabilities that make automation powerful make it dangerous when compromised.

AI agents are workflow automation with better marketing. They use LLMs for planning instead of visual node editors, but the execution model is the same: multi-step, tool-using, data-accessing, code-running autonomous systems. Every vulnerability class that affects n8n will affect AI agent frameworks.

The question isn’t whether AI agent sandboxes will fail. It’s when - and whether your security posture assumes they already have.

Rogue Security builds runtime behavioral security for agentic AI and workflow automation - detecting sandbox escapes, tool misuse, and anomalous execution before they compromise your infrastructure. Learn more at rogue.security.