n8n sandbox escape shows the blast radius of workflow control planes

At a glance

What this is: This is Cyera’s analysis of a critical n8n sandbox escape that shows how a workflow engine can become an organisation-wide automation control plane when post-auth code execution reaches stored secrets and connected systems.

Why it matters: It matters because IAM, PAM, and NHI teams should treat workflow engines as privileged trust hubs, not just low-risk automation tooling, especially when long-lived credentials and cross-system integrations are concentrated in one place.

By the numbers:

• CVE-2025-68668 in n8n has a CVSS score of 9.9 and enables post-auth remote code execution through a Pyodide sandbox escape.
• Cyera says its previous n8n disclosure, Ni8mare, was an unauthenticated remote code execution vulnerability with a CVSS score of 10.0.
• Cyera notes that n8n’s public workflow gallery contains 7,600+ published workflows.

Context

The primary governance problem is that workflow engines can hold delegated trust far beyond what teams usually model. When a platform is allowed to orchestrate SaaS, cloud, database, and identity actions from one place, a sandbox failure is no longer a local application defect but a trust-boundary collapse across the programme.

In this case, the issue is not simply code execution. It is that the execution layer sits beside long-lived credentials, privileged automations, and operational integrations, so a post-auth foothold can become access to many downstream systems at once.

That makes workflow control planes relevant to NHI, PAM, and emerging agentic AI operating models alike. If the platform can act with broad authority on behalf of users or automations, the security question shifts from app hardening to delegated execution governance.

Key questions

Q: What breaks when a workflow engine sandbox can be bypassed?

A: The platform stops behaving like a constrained automation tool and starts behaving like a privileged execution environment. If authenticated users can inject code past the sandbox, the security boundary shifts from the application layer to the server itself, and any secrets or integrations reachable by that server are now in scope. That is why workflow editor rights need privileged-access treatment.

Q: Why do workflow engines create such a large blast radius for attackers?

A: Workflow engines connect many systems through trusted credentials and automation logic, so a compromise can expose multiple NHIs at once. If the platform can read files, access databases, and execute actions, attackers can move from one vulnerable endpoint to broad operational control without needing separate exploits for each system.

Q: What are the signs that a workflow platform should be treated as a control plane?

A: Look for central orchestration of identity, data, and infrastructure actions; persistent secrets storage; and workflows that execute trusted business processes across multiple systems. When one platform brokers many high-value actions, a compromise affects governance and access control far beyond a single application.

Q: Should teams disable code execution or redesign the execution model in workflow platforms?

A: If code execution is required, the safer path is redesigning the execution model so untrusted code runs in a truly isolated runtime with no direct access to privileged process capabilities. Disabling the feature is a temporary containment measure, but capability removal is the stronger governance choice when the platform handles sensitive integrations.

Technical breakdown

Why blocklist sandboxes fail in workflow engines

A blocklist sandbox tries to stop dangerous behaviour by naming functions or modules that should not be used, such as OS command execution or browser bridges. That approach fails when the runtime still exposes alternate paths to the same capability. In Pyodide, code can sometimes reach native functionality through foreign function interfaces or other execution surfaces that were not explicitly blocked. The weakness is structural: the control is focused on known bad calls, not on removing the underlying privilege to execute them. In a workflow engine, that means a user-facing code node can still become a general execution engine if the sandbox is capability-complete rather than capability-restricted.

Practical implication: treat allowlisting, isolation, and runtime containment as the real control, not function blocking alone.

How post-auth RCE becomes workflow and secrets exposure

Once an attacker gains post-auth remote code execution inside the automation process, the compromise extends to whatever that process can read or invoke. In a workflow platform, that often includes stored secrets, execution context, credential stores, and connectors to SaaS, cloud, and internal services. The danger is not just data theft from one container. The danger is delegated trust, because the platform already holds tokens and permissions that were meant to automate legitimate business actions. A sandbox escape therefore turns one valid foothold into access to the same integrations and credentials that power the organisation’s day-to-day automation.

Practical implication: inventory every integration the workflow runtime can reach and classify the credentials it can present.

Why workflow platforms behave like control planes

Workflow orchestration tools are increasingly used to encode operational decisions, not just task automation. That means they sit between identity systems, business applications, and infrastructure services, acting as execution brokers for trusted actions. When a platform owns credential storage, workflow logic, and action dispatch, it becomes a control plane by function even if the product is marketed as automation. The architectural risk is concentration: the more systems and secrets one engine controls, the more valuable any escape or privilege abuse becomes. The blast radius is therefore determined by delegated authority, not by the original exploit surface alone.

Practical implication: model automation platforms as high-value control planes in your privilege and third-party risk reviews.

Threat narrative

Attacker objective: The attacker seeks to turn one workflow foothold into trusted access across the organisation’s connected systems and secret stores.

1. Entry begins with a low-privilege, post-auth account that can access and edit workflows in the n8n environment.
2. Credential access follows when the attacker escapes the Pyodide sandbox and runs code with the n8n process privileges, opening paths to stored secrets and runtime data.
3. Escalation occurs as the attacker can modify automations, change account state, and use trusted integrations to move through connected systems.
4. Impact is organisation-wide compromise of the automation control plane, including abuse of long-lived API keys, OAuth tokens, and database passwords.

Breaches seen in the wild

• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Workflow engines have become delegated control planes, not just task runners. When one platform can orchestrate cloud, SaaS, database, and identity actions, the security model must reflect concentrated authority rather than isolated app access. That changes how teams assess blast radius, because compromise is measured by the downstream trust the platform already holds. The practitioner conclusion is that automation platforms belong in the privileged tier of identity governance.

Blocklist sandboxing is a brittle governance assumption. It was designed for a world where defenders could enumerate dangerous calls and patch them out one by one. That assumption fails when the runtime still exposes alternate paths to the same capability, because capability remains present even when the obvious API is hidden. The implication is not merely to harden a feature, but to stop treating restricted code execution as if it were truly constrained execution.

Long-lived credentials turn workflow compromise into system-wide identity exposure. n8n’s model concentrates API keys, OAuth tokens, and database passwords inside the same execution environment that performs automation. Once that environment is compromised, the attacker inherits delegated authority that was meant to persist across many business flows. This is a classic identity blast-radius problem, and the practitioner conclusion is that credential placement and runtime scope must be governed together.

Agentic AI amplifies the same control-plane failure mode. As organisations use AI to trigger workflows, the workflow engine becomes the execution layer for decisions made elsewhere. That means the identity question is no longer only who can edit the workflow, but what authority the workflow can exercise on behalf of an automated decision loop. The practitioner conclusion is that agentic systems inherit the same blast-radius limits as the control planes they call.

Capability-based isolation is now the defining security boundary for code-execution features. The article shows that removing a few functions does not remove the power to spawn processes, reach sensitive files, or invoke privileged libraries. If the runtime can still access the capability, the sandbox has not really contained it. The practitioner conclusion is to treat untrusted code as a separate execution domain, not as a patched language feature.

What this signals

Identity blast radius is now the more useful control metric. The question is no longer whether a workflow engine can execute code, but what identities, secrets, and downstream systems it can reach if that code is abused. Programmes that do not map delegated authority from automation layers will underestimate their real exposure.

Workflow platforms that store credentials and execute trusted actions should be reviewed as part of privileged access governance, because the compromise path is from runtime to authority, not from one server to one app.

For practitioners

• Model workflow platforms as privileged control planes Map every n8n or similar workflow engine to the systems, identities, and secrets it can reach. Classify it alongside PAM and other high-trust execution surfaces, not as ordinary application middleware.
• Replace function blocklists with capability isolation Review any code-execution feature that relies on blocking specific calls such as process spawning or JavaScript bridges. Prefer runner-based or process-isolated execution models that remove the underlying capability instead of naming bad functions.
• Inventory long-lived credentials inside automation runtimes Identify API keys, OAuth tokens, database passwords, and similar secrets stored or reachable from workflow engines. Separate high-value credentials from code-execution paths wherever the platform can run untrusted logic.
• Limit workflow authoring privileges to the minimum necessary Reduce the number of accounts that can create or edit workflows, especially where code nodes are enabled. Treat workflow editing rights as privileged access because they can indirectly reach production integrations and data.
• Test incident paths for control-plane compromise Exercise what happens when a workflow engine is compromised, including secret exposure, workflow tampering, and cross-system abuse. Use those scenarios to define containment, revocation, and recovery priorities before an exploit occurs.

Key takeaways

• The core risk is delegated trust concentration, where a workflow engine can reach far more than its user interface suggests.
• Cyera ties the issue to a 9.9-rated post-auth RCE and a prior unauthenticated n8n flaw, which together show a recurring pattern in workflow automation security.
• The practical control lesson is to remove underlying runtime capability, not to rely on blocks around individual functions or APIs.

Key terms

• Workflow control plane: The part of an application environment that decides who can trigger a process, what the process does, and how the resulting evidence is retained. For identity teams, it is where business automation and access governance overlap most visibly.
• Sandbox Escape: A sandbox escape is when code breaks out of its intended isolation boundary and gains access to host capabilities. In identity terms, it turns a constrained non-human execution path into a privileged runtime that can touch files, secrets, or downstream systems.
• Capability-based isolation: A design approach that removes dangerous powers from untrusted code rather than trying to block individual risky functions. It is stronger than a blocklist because the runtime simply does not expose the capability needed to spawn processes, reach sensitive files, or call protected services.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.