n8n sandbox escape shows how workflow automation can become takeover

At a glance

What this is: This is a research report on critical n8n sandbox escape flaws that turned ordinary workflow editing into server takeover and credential theft.

Why it matters: It matters because workflow automation platforms increasingly sit inside identity and secrets paths, so one sandbox failure can expose NHI credentials, cloud access, and AI pipeline trust boundaries.

By the numbers:

• CVSS 3.1 Score: 10.0 Critical, CVE-2026-25049

👉 Read Pillar Security's full research on the n8n sandbox escape and credential takeover

Context

n8n is a workflow automation platform, but in enterprise environments it often becomes a control plane for credentials, APIs, and AI-enabled processes. When that platform evaluates user-provided code on the server, the real issue is not convenience but whether the runtime boundary can contain untrusted input.

This report shows what happens when that boundary fails. The primary governance problem is that a workflow editor can become a server operator, which turns ordinary automation into privileged execution and makes NHI secrets, cloud keys, and AI pipeline connections part of the same blast radius.

For identity teams, the lesson is broader than one product. Any platform that stores or uses secrets while executing user-supplied logic needs the same scrutiny as a privileged application tier, because workflow ownership can quickly become infrastructure ownership.

Key questions

Q: What breaks when a workflow platform can evaluate user code on the server?

A: The control boundary breaks because the platform is no longer only moving data between systems. User-authored logic can reach process memory, environment variables, and stored secrets, which means ordinary workflow editing can become privileged execution. Security teams should assume server-side code evaluation creates an infrastructure-level trust problem, not just an application-layer input issue.

Q: Why do workflow automation platforms create NHI risk when they store secrets?

A: They create NHI risk because the same runtime that executes workflows often also decrypts or handles API keys, OAuth tokens, and cloud credentials. If an attacker escapes the sandbox, those non-human identities become reachable through the automation plane. The practical result is that orchestration and secret custody cannot share the same weak trust boundary.

Q: How do security teams know whether sandbox controls are actually working?

A: They know by testing for alternate expressions of the same action, not by checking whether one blocked syntax case still fails. A sandbox is weak if template literals, reflective APIs, indirect property writes, or call arguments can still produce the same privileged effect. The right signal is whether equivalent behaviour is contained across different language forms.

Q: Who is accountable when a workflow editor can expose stored credentials?

A: Accountability sits with the teams that own the automation platform, the secret store, and the surrounding identity controls. If a workflow editor can reach stored credentials, then access governance, runtime isolation, and secrets management are shared responsibilities, not separate problems. The control failure is architectural, so the accountability model has to be too.

Technical breakdown

How the expression sandbox became an execution boundary failure

n8n evaluates expressions server-side inside a JavaScript sandbox. The platform tries to block dangerous globals, inspect abstract syntax tree nodes, and sanitize prototype access, but that approach depends on predicting every way JavaScript can express the same action. The first flaw came from incomplete property inspection: template literals could bypass a denylist that caught dot notation and quoted strings. Once the sandbox let attacker-controlled code reach V8 stack hooks, the runtime handed over access to the real global object, which ended the boundary. This is a classic case where sanitization around code execution is weaker than execution isolation.

Practical implication: treat server-side expression evaluation as a privileged execution boundary, not an input-validation problem.

Why AST sanitisation missed call-expression abuse

The second bypass exposed a different blind spot. The patch blocked one syntax path, but the sandbox only inspected member access, not function-call arguments. That meant dangerous strings could be passed through APIs such as Object.defineProperty without being recognised as sensitive operations. In security terms, the control failed because it matched syntax patterns rather than behaviour. When a sandbox assumes all risky actions look like property reads or writes, attackers only need another JavaScript construct to express the same intent.

Practical implication: inspect runtime behaviour and API effects, not just the syntax forms you expect attackers to use.

Credential exposure turns sandbox escape into NHI takeover

Once command execution was possible, the impact moved from code execution to identity compromise. n8n stores environment variables, encryption keys, API tokens, OAuth secrets, and cloud credentials in a context the sandbox could reach after escape. That means the platform was not only running workflows, it was holding non-human identity material in the same operational trust domain as user-authored code. In multi-tenant cloud deployments, the consequence expands from a single server to shared services and customer data paths, which is why this class of flaw sits squarely in NHI governance.

Practical implication: separate workflow execution from secret custody so one compromise cannot expose every stored credential.

Threat narrative

Attacker objective: The attacker objective is to turn workflow-editing access into full server control and downstream credential theft across automation and AI-connected systems.

1. Entry began with an authenticated workflow editor using the expression feature that the platform allowed by design.
2. Credential access followed when sandbox escape exposed the server process, environment variables, stored secrets, and connected cloud credentials.
3. Impact came through command execution, credential decryption, and the ability to pivot into AI pipelines and shared cloud services.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Execution isolation, not sanitisation, is the real trust boundary for workflow platforms: This breach worked because the platform assumed hostile code could be safely filtered after submission. That assumption fails when a workflow engine is expected to run arbitrary expressions as part of normal operation. The implication is that identity and secrets governance for automation platforms must start from containment, not pattern-matching.

Sandbox escape is a non-human identity failure, not just an application bug: The compromised server held API keys, OAuth tokens, cloud credentials, and encryption material in the same operational scope as user-controlled logic. That collapses the boundary between the identity that executes workflows and the identities those workflows can reach. Practitioners should read this as a governance failure in secrets custody, not a narrow code defect.

Identity blast radius expands when orchestration becomes the control plane: Workflow tools increasingly sit between human intent, NHI credentials, and AI pipeline execution. Once a single workflow editor can affect stored secrets and connected systems, the platform becomes a privileged broker rather than a neutral automation layer. The practitioner conclusion is that blast-radius design has to cover the orchestration tier itself.

Template-literal filtering exposed a deeper control-model problem: The first patch fixed one syntax form but left the underlying execution model intact. That is a named failure mode we see repeatedly in NHI governance: partial syntax controls create a false sense of containment while equivalent expressions still reach the same privileged effect. Teams need to recognise when a control is narrowing an attack path rather than closing the trust boundary.

Multi-tenant automation increases the consequences of credential exposure: In a shared cloud service, one compromised tenant can become a platform-wide incident if internal services and customer data are reachable from the same execution plane. That shifts review priorities from tenant permissions alone to service isolation, internal API exposure, and credential segregation. Identity teams should treat shared automation platforms as high-consequence infrastructure.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• That governance gap becomes more dangerous when workflows and agents share credential paths, as the The 52 NHI breaches Report shows through repeated credential-exposure patterns.

What this signals

Identity blast radius is now a platform question as much as a credential question. When a workflow engine can decrypt secrets and reach connected services, the unit of governance shifts from the individual workflow to the entire orchestration plane, which is why teams should reassess where execution, storage, and privilege intersect.

The practical signal for practitioners is that low-code and automation platforms need the same scrutiny as privileged middleware. If your programme cannot answer which workflows can reach which secrets, then you do not yet have workable containment for either NHI or AI-driven automation.

Use the OWASP Agentic AI Top 10 and the OWASP NHI Top 10 as a starting point for reviewing runtime trust boundaries, then map those findings to the automation layer that actually executes the logic.

For practitioners

• Map every server-side expression path Inventory where workflow, transformation, or rule engines execute user-controlled logic on the server. Classify each path by whether it can reach process memory, environment variables, or secret stores, and remove assumptions that expression evaluation is harmless just because it is embedded in a low-code UI.
• Separate secret custody from workflow execution Store API keys, OAuth tokens, and cloud credentials outside the runtime that evaluates workflows. If the automation plane must decrypt secrets, place a stronger isolation layer between the evaluator and the credential store so one sandbox failure cannot expose every stored secret.
• Test for equivalent-expression bypasses Review sanitisation controls for alternate syntax forms, API calls, and object-manipulation methods that produce the same effect as blocked operations. Focus on call arguments, reflective methods, and indirect property writes, because attackers will use whichever construct the sanitizer forgot.
• Reduce the blast radius of shared automation services On multi-tenant platforms, isolate internal services, restrict lateral reach from orchestration containers, and verify that customer workflows cannot touch shared management APIs or internal registries. Shared execution infrastructure should never imply shared trust.
• Apply NHI governance to automation platforms Treat workflow engines that store credentials as NHI control surfaces. Revisit offboarding, rotation, access reviews, and key scoping for every secret that can be reached by a user-authored workflow, especially where AI pipelines depend on the same platform.

Key takeaways

• The breach shows that workflow automation platforms can become privileged execution environments when server-side code evaluation is not fully contained.
• The impact was not limited to code execution, because stored secrets, cloud credentials, and AI pipeline access all sat inside the same trust domain.
• Execution isolation and secret segregation would have limited the blast radius far more effectively than syntax-based sanitisation alone.

Key terms

• Workflow Execution Boundary: The workflow execution boundary is the point where user-authored logic stops being data transformation and starts becoming privileged runtime activity. In secure designs, that boundary prevents untrusted workflow content from reaching process memory, system calls, or secret stores without strict containment.
• Sandbox Escape: A sandbox escape happens when code restricted to a limited runtime breaks out and gains access to host resources, such as the filesystem, environment variables, or process privileges. In automation platforms, the impact is often credential exposure and downstream system compromise, not just local code execution.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and downstream systems that can be affected when one identity or runtime is compromised. For automation platforms, it expands when workflow execution, secret custody, and internal service access sit inside the same trust domain.
• Secrets Custody: Secrets custody is the operational responsibility for storing, decrypting, and exposing credentials only to the systems that truly need them. In workflow and agent platforms, weak custody means a runtime compromise can reveal API keys, OAuth tokens, certificates, and cloud credentials at once.

Deepen your knowledge

Workflow platform sandboxing and non-human identity custody are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing automation platforms that also handle secrets, it is worth exploring.

This post draws on content published by Pillar Security: n8n sandbox escape and complete server takeover through critical vulnerabilities. Read the original.