Isometric diagram showing a dark server chassis with an expression evaluator unit. An empty mounting frame at the evaluator's input boundary has no barrier plate installed. An amber signal beam passes through the empty frame and strikes the execution module, which glows amber. Teal circuit traces terminate at the frame edge without connecting to the execution path.

Runtime Security Boundaries Require Runtime Enforcement: Lessons from n8n’s CVE Chain

by

Table of Contents

Executive Summary

Five critical vulnerabilities in n8n’s expression evaluation sandbox – four rated CVSS (Common Vulnerability Scoring System) 9.9 to 10.0 and one rated 9.4, disclosed between December 2025 and February 2026 – are not a string of independent bugs. They are the predictable output of a single architectural decision: using TypeScript’s compile-time type system as a runtime security enforcement mechanism. Because TypeScript annotations are erased before code executes as JavaScript, any sanitization check conditioned on a TypeScript-declared type is invisible to the running process. An attacker who supplies a value of a different runtime type bypasses the check without touching the sandbox logic. The fifth CVE, CVE-2026-25049 published in February 2026, bypasses the patch for CVE-2025-68613 using the same mechanism – because the patch operated within the same broken design model. Self-hosted n8n instances prior to versions 1.123.17 or 2.5.2 are exposed to CVE-2026-25049. Teams using n8n to orchestrate LLM (Large Language Model) agent pipelines face a materially larger blast radius: a sandbox escape grants access not just to the host OS, but to every model API key, database credential, and enterprise connector the agent holds. Patch to the latest versions covering all five CVEs and audit any publicly accessible webhook endpoints for authentication requirements.

The Pattern: What We Keep Getting Wrong

The pattern is Compile-Time Enforcement at a Runtime Boundary. It appears when a security boundary – a sandbox, a sanitization check, an access control gate – is implemented using a construct that exists only during static analysis or compilation, while the runtime process has no awareness of that construct and cannot enforce it on attacker-controlled input. The pattern shares a structural relationship with trust boundary failures in AI agent architectures, where enforcement assumptions hold during development but collapse under adversarial runtime conditions.

TypeScript’s type system is the canonical example. TypeScript enforces type safety at compile time – it is designed for development-time code correctness, not runtime security enforcement. Type annotations are erased before the JavaScript runtime executes. A parameter declared as string in TypeScript source carries no runtime constraint: the executing process cannot check, reject, or observe the declared type of a value it receives. An attacker supplying an object where a string is expected does not “bypass” a TypeScript check – the check does not exist in the process they are attacking.

This distinction matters for how teams reason about patches. When the fix for a type confusion sandbox escape adds another TypeScript type check, it adds another check that is also erased at runtime. The pattern recurs because the fix changes the specific syntax, not the enforcement model. Security constraints at a trust boundary must be enforced in the runtime – using explicit assertions that execute where the attacker operates. This is the same lesson illustrated by recurring security feature bypass patterns in Microsoft’s February 2026 Patch Tuesday, where patches that address the specific vector without fixing the underlying enforcement model invite repeated bypass.

Evidence Base: Recent Instances

n8n is a workflow automation platform used to build LLM-powered agent pipelines, connecting AI models to databases, APIs, identity providers, and CI/CD pipelines. As CSO Online reported, n8n is explicitly positioned for this AI agent orchestration use case.

Five critical vulnerabilities in the same component over 90 days exhibit the pattern directly:

  • CVE-2025-68613 (CVSS 9.9, December 2025, NVD): Expression injection in the sandbox. Authenticated. Patched in 1.120.4, 1.121.1, and 1.122.0.
  • CVE-2026-21858 (“Ni8mare”, CVSS 10.0, January 2026, NVD): Unauthenticated RCE (Remote Code Execution) via Content-Type confusion in formWebhook. PoC (Proof of Concept) published on GitHub. The Canadian Centre for Cyber Security issued Advisory AL26-001 covering this CVE. An estimated 100,000+ instances were exposed at disclosure. In-the-wild exploitation not confirmed in Tier 1 sources as of February 17, 2026.
  • CVE-2026-21877 (CVSS 10.0, January 2026, Canadian Centre for Cyber Security AL26-001): Unrestricted file upload enabling code execution. Chainable with CVE-2026-21858. Patched in 1.121.3.
  • CVE-2025-68668 (“N8scape”, CVSS 9.9, January 2026, Rapid7): Authenticated sandbox bypass via a different bypass path than the type confusion mechanism. Patched in 2.0.0. Included here because it demonstrates the same sandbox mechanisms not holding under adversarial pressure, not the identical root cause.
  • CVE-2026-25049 (CVSS 9.4, February 2026, The Hacker News): Sandbox escape that explicitly bypasses CVE-2025-68613’s patch by the same type confusion mechanism. Ten researchers credited. Patched in 1.123.17 and 2.5.2. No confirmed in-the-wild exploitation as of February 17, 2026.

Scoring note: The CVSS 9.4 for CVE-2026-25049 is sourced from The Hacker News; the scoring organization and provisional status are not identified in available sources. CVE-2026-21858 is not listed in CISA (Cybersecurity and Infrastructure Security Agency) KEV (Known Exploited Vulnerabilities) as of February 17, 2026. n8n Cloud (SaaS) exposure is not documented in available sources; this analysis is scoped to self-hosted deployments.

Mechanics: How the Pattern Enables Attack

The CVE-2026-25049 attack chain illustrates the pattern directly:

  1. Authenticate or acquire workflow access. The attacker holds credentials with workflow creation or editing rights – obtained via credential theft, phishing, or account takeover. Unauthenticated path: at least one workflow exposes a publicly accessible webhook without authentication controls.
  2. Craft a malicious expression using JavaScript destructuring syntax. The attacker constructs an expression parameter that is an object or array at runtime – satisfying TypeScript’s compile-time string annotation, but a non-string type when the process executes.
  3. Trigger workflow execution. The attacker fires the workflow via webhook, schedule, or manual trigger.
  4. Sanitization check bypassed via type confusion. The sanitization logic checks whether the parameter is a string. The attacker’s object fails that condition – the check does not fire. As Endor Labs researcher Cris Staiku explained: “TypeScript cannot enforce these type checks on runtime attacker-produced values. When attackers craft malicious expressions at runtime, they can pass non-string values…that bypass the sanitization check entirely.”
  5. OS command execution. The unsanitized value reaches the Execute Command node and runs with the n8n server process privileges.

CVE-2026-21858 “Ni8mare” – detailed by Cyera Research Labs – requires no authentication: an HTTP POST with application/json Content-Type bypasses the multipart/form-data gate in formWebhook, enabling system file path traversal, session cookie forging from exfiltrated secrets, and RCE via the Execute Command node. The unauthenticated webhook path shares a structural similarity with Fortinet’s CVE-2026-24858, where a security control that appeared effective during design review failed to constrain attacker behavior at the actual enforcement point.

The pattern enables both attacks because the enforcement layers protecting the Execute Command node did not exist in the runtime environment where the attacker operates. Any expression evaluator or webhook endpoint that enforces security constraints via compile-time constructs or client-declared headers is susceptible to the same class, regardless of product or CVE.

Pattern: Compile-Time Enforcement at a Runtime Boundary

Preconditions: A sandbox uses compile-time constructs (TypeScript annotations, linting rules, compile-time schema generation) as the runtime enforcement mechanism; attacker-controlled values reach the boundary from outside the compile-time analysis context; the boundary connects user-controlled input to a privileged execution layer.

How it enables attack: The attacker supplies a value whose runtime type differs from the TypeScript-declared type, using JavaScript features that produce non-string runtime types. The compile-time constraint does not exist at runtime; the sanitization check is bypassed silently.

Detection signals: Expression evaluator receiving objects or arrays where strings are expected (requires runtime type logging); anomalous child process spawning from the n8n parent; unexpected file access to credential files or system paths.

Mitigations: Explicit typeof or schema validation (Zod, Joi) at the expression evaluator input boundary, independent of TypeScript annotations (for teams building expression evaluators); a separate runtime authorization layer between the evaluator and the Execute Command node; OS process isolation for the evaluator subprocess with no access to application secrets; authentication on webhook endpoints by default (a compensating control that reduces attack surface, not a fix for the root cause architectural pattern).

Residual risk: New workflow primitives added to the platform may reintroduce type confusion surfaces if the runtime enforcement requirement is not mandated for all new expression-handling code paths.

Threat Model Implications

Many teams assume TypeScript’s type annotations provide type safety in their JavaScript execution environment. This vulnerability family demonstrates that TypeScript annotations are erased before runtime – the executing process has no knowledge of declared types and cannot enforce them on attacker-controlled values. Every security-relevant type check must be implemented as an explicit runtime assertion, using typeof, instanceof, or a schema validation library, at the point where attacker-controlled data enters the security boundary – not inferred from TypeScript source declarations. Those assertions must then be tested adversarially with non-string inputs, not only with valid strings that confirm the happy path.

Many teams assume that patching a sandbox bypass closes the escape surface for that vulnerability class. CVE-2026-25049 is direct counter-evidence: it bypassed CVE-2025-68613’s patch by the same mechanism, because the patch added a check within the same flawed trust model rather than changing the model. When a patch and its bypass share the same underlying mechanism, the fix changed the specific vector but not the architectural condition. Patch validation for sandbox escapes must confirm that the fix changes the trust model – not only that it blocks the reported PoC. A review that cannot articulate what trust model change the patch makes should be treated as an incomplete fix.

Teams using n8n to orchestrate LLM agent pipelines face a blast radius that exceeds what a general workflow automation threat model predicts. The n8n process holds API keys for LLM providers, vector database credentials, and enterprise connector secrets as ambient state. A sandbox escape grants access to every system the AI agent pipeline reaches – not just the host OS. This ambient credential escalation pattern is not unique to n8n — it occurs wherever platform processes accumulate API keys and connector secrets beyond what individual workflows require. Teams should inventory all credentials accessible to the n8n process and apply credential segmentation (storing secrets in a dedicated vault such as HashiCorp Vault or a cloud provider secrets manager, accessible only to the specific workflow components that require them) so AI model API keys are not available as ambient environment variables across the full process. Process-level least-privilege does not undo application-level credential over-scoping: an n8n process with restricted OS privileges still holds all the API credentials it has been configured with.

Isometric diagram showing a dark server chassis with an expression evaluator unit. A solid barrier plate fills the mounting frame at the evaluator's input boundary. An amber signal beam deflects off the barrier plate. Teal circuit traces connect the barrier plate to the execution module, which glows teal indicating no bypass.
Runtime security enforcement requires runtime checks — not source-code annotations. A barrier plate installed in the execution path deflects the attack regardless of what the source declared.

The Design Principle: What Correct Looks Like

Systems that enforce security correctly at a runtime trust boundary do not delegate that enforcement to the type analyzer, the linter, or the compiler. They apply runtime assertions – explicit checks that execute in the same environment where the attacker operates – at every point where attacker-controlled data enters the security boundary.

For teams building expression evaluators or custom sandbox systems: before any sanitization logic runs, verify the value is a string using typeof value === ‘string’ or schema validation. If it is not a string, reject it. This check must live in the JavaScript runtime, not in TypeScript source declarations. It must be tested adversarially – with object inputs, array inputs, and deeply nested destructuring patterns – not only with valid strings that confirm the happy path.

For n8n operators: patch to the latest covered versions, audit webhook authentication, and inventory credentials accessible to the n8n process. These are the controls within your scope. Runtime type enforcement inside the evaluator is n8n’s engineering responsibility; your responsibility is ensuring you run the patched version and reduce the attack surface via authentication controls and credential segmentation.

Runtime type enforcement around the expression evaluator is necessary but not sufficient. Teams building AI workflow platforms with OS-level command execution capability should also apply an independent runtime authorization layer that checks whether the specific workflow has been explicitly permitted to invoke the Execute Command node – independent of sandbox integrity. To identify whether existing systems exhibit this pattern, examine every security check that tests a TypeScript-typed condition on a value from user input, webhook payloads, or API calls: if the security property is derived from the TypeScript annotation rather than a runtime assertion, it is exploitable by the same mechanism.

OWASP Reference Mapping

OWASP Top Ten 2021: A04:2021 Insecure Design

A04:2021 focuses on design and architectural failures – risks related to design flaws where security requirements were not incorporated into the architecture, rather than implementation-level bugs alone. This incident maps because n8n’s expression sandbox was designed with TypeScript type annotations as the runtime enforcement mechanism, making runtime enforcement architecturally impossible since TypeScript annotations do not exist at JavaScript runtime. The December 2025 patch applied a type check within the same flawed design and was bypassed two months later by the same mechanism – the hallmark of A04:2021 is that patches which do not address the design failure are insufficient. For product teams: when a sandbox bypass CVE is immediately followed by a patch-bypass of the same class, the diagnostic is Insecure Design. The question is not “how do we add a better type check?” but “does our design allow runtime enforcement of security constraints, independent of compile-time constructs?”

Reference: OWASP Top Ten 2021 – A04 Insecure Design

OWASP LLM Top 10 (2025): LLM06:2025 Excessive Agency

LLM06:2025 covers AI agents given more capabilities or autonomy than required, particularly when those permissions extend to system-level actions. This incident maps because n8n’s Execute Command node provides AI workflows with direct OS-level command execution. In an LLM agent deployment, the sandbox was the only constraint between a workflow expression and that execution capability. When the sandbox failed, the full Excessive Agency surface became available: host OS access plus all model API keys, database credentials, and enterprise connectors the agent holds. The machine identity governance crisis created by shadow AI deployments amplifies this risk — organizations that lack visibility into which AI agent pipelines exist cannot assess which n8n instances hold over-scoped credentials. For product teams: AI workflow platforms that give agents command execution capability must treat the sandbox as one defense-in-depth layer, not the only constraint. Defense-in-depth requires scoping what the Execute Command node can reach even when the sandbox is intact.

Reference: OWASP Top 10 for Large Language Model Applications

OWASP API Security Top 10 (2023): API8:2023 Security Misconfiguration

API8:2023 covers APIs deployed with insecure configurations that create exploitable gaps. This incident maps through CVE-2026-21858’s formWebhook vulnerability: the endpoint gated file path processing on the Content-Type header, treating multipart/form-data as the authorization signal. Content-Type is client-declared and attacker-controlled – it requires no privilege to set to any value. Any unauthenticated actor who sent a different Content-Type bypassed the gate entirely. The durable design rule: webhook endpoints that receive mixed request types must validate body structure server-side, not delegate security decisions to client-declared headers, regardless of the Content-Type value claimed. Authorization gates must be based on verifiable, server-controlled signals.

Reference: OWASP API Security Top 10 2023 – API8 Security Misconfiguration

Counterfactual Analysis

Runtime type validation at the expression evaluator input boundary would have blocked the CVE-2026-25049 attack at step 4 with high confidence. A typeof value === ‘string’ assertion before the sanitization check would have rejected the attacker’s object before it bypassed the check. Caveat: this does not address CVE-2025-68668 (“N8scape”), which uses a different bypass path in the same component.

Requiring authentication on all webhook endpoints by default would have blocked the unauthenticated attack path for both CVE-2026-21858 and the public-webhook CVE-2026-25049 variant with high confidence. The “Ni8mare” chain depends entirely on unauthenticated formWebhook access. Caveat: an attacker with workflow creation credentials – via phishing or credential compromise – could still exploit CVE-2026-25049 via the authenticated path. Organizations evaluating their authentication posture should also consider how MFA bypass techniques like synchronized vishing and real-time relay can undermine credential-based controls that appear robust.

OS process isolation for the expression evaluator subprocess would have reduced the blast radius at medium confidence – OS commands in an isolated process with no access to application secrets would not have reached LLM API keys or enterprise credentials. Caveat: isolation does not prevent the attacker from probing network-accessible services reachable from the host, including cloud provider metadata endpoints that can yield IAM (Identity and Access Management) credentials, and is ineffective if model API keys are mounted as environment variables in the evaluator subprocess.

What Product Teams Commonly Miss

  1. For teams building expression evaluators or custom workflow platforms: Does your expression evaluator validate the runtime type of attacker-supplied values explicitly – with typeof or a schema validator – independent of TypeScript annotations? A TypeScript annotation is not a runtime check. (Attack chain step 4)
  2. For teams building or maintaining expression evaluators and custom sandbox systems: When you patched a sandbox bypass, did the review confirm the fix changes the trust model, or only that it blocks the reported PoC? If the fix adds a check within the same enforcement layer that was bypassed, the root cause has not been addressed. (Attack chain step 4 – patch bypass)
  3. What credentials are accessible to the process running your AI workflow engine? If that process were compromised today, what is the full blast radius across model API keys, vector database credentials, and enterprise data connectors? (Attack chain step 5)
  4. Are any workflows configured with publicly accessible, unauthenticated webhooks? Have you enumerated every such endpoint and confirmed each exposure is intentional and reviewed? (Unauthenticated path, step 1)
  5. For every Execute Command or equivalent privileged node, is there an independent runtime authorization check separate from the sandbox? Or does sandbox integrity serve as the only constraint? (Attack chain step 5)
  6. For teams building expression evaluators or custom sandbox systems: When was your evaluator last tested with non-string inputs – nested objects, arrays, prototype-manipulating values? Tests against expected string inputs do not cover this attack class. (Attack chain step 2)

Non-Goals

This analysis does not apply to n8n Cloud (SaaS) users. n8n Cloud’s exposure to CVE-2026-25049 and related CVEs is not documented in available sources. Organizations on n8n Cloud should contact n8n directly rather than applying self-hosted mitigation guidance.

This analysis does not imply that TypeScript itself is insecure or an inappropriate choice for web application development. TypeScript’s type system is designed for development-time type safety and code correctness – it is explicitly not designed to be a runtime security enforcement mechanism. The failure in this incident was an architectural decision to use TypeScript annotations for a purpose they were never designed for. TypeScript used in projects where runtime security enforcement is implemented independently is entirely appropriate.

The OWASP Excessive Agency mapping does not apply to n8n deployments used only for non-AI workflow automation without LLM integration. The AI-specific blast radius analysis is scoped to deployments that use n8n as an LLM agent orchestrator. n8n deployments that do not connect AI models to enterprise systems via the workflow platform are affected by the same CVEs but do not face the AI-specific Excessive Agency risk.

Recommendations

Immediate (all self-hosted n8n operators)

  • Patch all five CVEs. Update all self-hosted n8n instances to versions covering CVE-2026-25049 (1.123.17 / 2.5.2), CVE-2026-21858 (1.121.0), CVE-2026-21877 (1.121.3), CVE-2025-68613 (1.120.4 / 1.121.1 / 1.122.0), and CVE-2025-68668 (2.0.0). A single-CVE patch plan is insufficient for this family.
  • Audit webhook authentication. Enumerate every workflow with a publicly accessible webhook (via n8n’s workflow list or the n8n API). For each unauthenticated endpoint, confirm the exposure is intentional and apply authentication controls where it is not explicitly required. For small teams without dedicated security infrastructure, these two actions – patch and webhook audit – address the highest-risk attack paths within existing operational scope.

Residual risk after Immediate actions: Patching and webhook authentication controls close the direct exploitation paths. Organizations that have not yet applied credential segmentation remain exposed to an elevated blast radius if a future vulnerability or misconfiguration results in process compromise — all API keys and connector secrets accessible to the n8n process are still at risk until the Short-term actions below are implemented.

Short-term (30-90 days)

  • Inventory AI-specific credential exposure. For n8n deployments used as LLM agent orchestrators, inventory all API keys and connector secrets accessible to the n8n process. Apply credential segmentation using a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, or equivalent) so model API keys are accessible only to the components that require them, not as ambient environment variables.
  • For teams building custom expression evaluators: Add runtime type assertions at the point where attacker-controlled values enter the evaluator, using explicit typeof checks or schema validation (Zod, Joi, or equivalent), independent of TypeScript annotations. Require the same pattern for all new expression-handling code paths as a development gate.

Strategic (all organizations)

  • Require architectural review for all sandbox bypass patches. Establish a review gate: does this patch change the trust model, or add a check within the same enforcement layer that was bypassed? A documented question checklist applied by the developer and a second reviewer before merging any sandbox patch is the minimum viable implementation. If the latter condition is true, treat the patch as incomplete and schedule architectural remediation.
  • Apply Excessive Agency controls to AI workflow platforms. For teams building AI workflow platforms: add a runtime authorization layer between the expression evaluator and any privileged execution node, independent of sandbox integrity. Scope agent capability to the minimum required for each workflow’s business function.

Frequently Asked Questions

How does an n8n sandbox escape happen through type confusion?

The n8n expression sandbox relied on TypeScript type annotations for sanitization — but TypeScript types are erased before JavaScript executes. An attacker supplies an object or array where a string is expected. Because the runtime process has no knowledge of the declared type, the sanitization check never fires, and the unsanitized value reaches the Execute Command node for OS-level code execution.

Why did patching CVE-2025-68613 fail to prevent CVE-2026-25049?

The December 2025 patch for CVE-2025-68613 added another type check within the same compile-time enforcement model that was already broken. Because the fix operated inside the same flawed trust model rather than introducing runtime assertions, CVE-2026-25049 bypassed it two months later using the identical type confusion mechanism — changing the specific syntax but not the architectural condition.

What makes AI agent deployments on n8n higher risk than standard workflows?

The n8n process in AI agent deployments holds LLM provider API keys, vector database credentials, and enterprise connector secrets as ambient state. A sandbox escape grants access to every system the agent pipeline reaches — not just the host OS. Standard workflow deployments face the same CVEs but lack the amplified blast radius created by accumulated AI-specific credentials and model access tokens.

What runtime checks should replace TypeScript type annotations at security boundaries?

Teams building expression evaluators should apply explicit typeof assertions or schema validation libraries such as Zod or Joi at every point where attacker-controlled data enters the security boundary. These checks must execute in the JavaScript runtime — not exist only in TypeScript source. They must be tested adversarially with object inputs, array inputs, and destructuring patterns, not only with valid strings.

How should self-hosted n8n operators prioritize remediation?

Patch all five CVEs immediately — a single-CVE patch plan is insufficient for this vulnerability family. Audit every publicly accessible webhook endpoint and apply authentication controls where exposure is not explicitly required. Within 30 to 90 days, inventory all credentials accessible to the n8n process and apply credential segmentation using a dedicated secrets manager so API keys are not stored as ambient environment variables.

References