n8n sandbox escape shows the blast radius of workflow control planes

At a glance

What this is: Cyera Research Labs describes a critical n8n sandbox escape that turns post-auth code execution into a compromise of the automation control plane.

Why it matters: IAM, NHI, and AI workflow teams need to treat automation runtimes as privileged identity surfaces because one compromise can expose credentials, modify workflows, and pivot into connected systems.

By the numbers:

• n8n’s public workflow gallery contains 7,600+ published workflows, which is a useful proxy for how broadly teams use it across business and IT automation.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Cyera’s analysis of the n8n sandbox escape and CVE-2025-68668

Context

n8n is a workflow automation platform that often sits between identity systems, SaaS applications, cloud APIs, databases, and internal services. In that role, it becomes part of the identity and access fabric, not just a convenience layer. When code execution inside that fabric can be escaped, the problem is no longer limited to application security.

For NHI and IAM programmes, the governance failure is structural: platforms that hold long-lived secrets and execute privileged actions are being used as trusted control points without equally strong isolation boundaries. That creates an oversized blast radius for service accounts, API keys, and tokens, especially when those credentials are reused across business-critical integrations.

Key questions

Q: What breaks when a workflow engine can execute untrusted code inside the same environment that stores secrets?

A: The boundary between application logic and trusted automation collapses. An attacker who reaches the execution path can often read secrets, change workflows, and issue actions that downstream systems treat as legitimate. That turns a single platform compromise into a control-plane event, which is why code execution features in orchestration tools must be isolated from secret-bearing contexts.

Q: Why do workflow platforms create outsized NHI risk in enterprise environments?

A: Because they concentrate long-lived credentials, delegated access, and execution authority in one place. If the platform is compromised, the attacker may inherit access to multiple systems through service accounts, API keys, or tokens that were never meant to be reachable from code execution. The risk is the trust concentration, not the workflow count alone.

Q: How do security teams know whether an automation platform has become too privileged?

A: Look for signals that the platform can both modify automations and reach sensitive credentials or identity state. If one account or runtime can edit workflows, access secret stores, and call downstream systems, the trust boundary is too wide. A healthy design makes those capabilities separable and observable, with clear administrative and execution boundaries.

Q: Who is accountable when a workflow platform compromise leads to downstream cloud or SaaS abuse?

A: Accountability sits with the teams that granted and governed the delegation chain, not only with the application owner. Identity, platform, and security teams should define who owns workflow permissions, secret exposure, runtime isolation, and incident response when automation becomes the entry point to wider systems.

Technical breakdown

Pyodide sandbox escape and capability leakage

n8n’s Python execution path used Pyodide, which runs Python in a browser-like runtime backed by WebAssembly. The platform applied blocklists to specific dangerous functions such as os.system, but blocklisting is not the same as removing capability. If the runtime still exposes foreign-function interfaces or alternate evaluation paths, untrusted code can reach the same underlying operating-system primitives by a different route. That is why sandbox design has to be capability-based, not function-name-based.

Practical implication: review any embedded code runtime for alternate execution paths, not just blocked APIs.

Why a workflow engine becomes a control plane

A workflow engine like n8n is often wired to SaaS, cloud, data, and identity services through long-lived credentials. That means it does not merely run tasks, it authorises actions across multiple systems. Once an attacker gets code execution inside the engine, they can usually read stored secrets, alter automation logic, and issue trusted requests that look legitimate to downstream platforms. The architectural failure is the concentration of identity, execution, and orchestration in one place.

Practical implication: isolate workflow runtimes from secret stores and constrain the credentials they can reach.

Post-auth RCE and privilege escalation through stored credentials

This vulnerability is dangerous because the attacker does not need to start with anonymous access to the internet-facing service. A low-privilege authenticated foothold inside the platform can be enough if code execution lets the attacker access the underlying database or configuration state. In an automation platform, that can translate into credential harvesting, workflow tampering, and escalation from a single user context into administrative control over connected systems. The impact is broader than classic server RCE because the platform already holds the trust relationships.

Practical implication: treat workflow-authoring permissions as sensitive and separate them from access to credentials and admin state.

Threat narrative

Attacker objective: The attacker aims to turn a single workflow-platform foothold into control over secrets, automations, and connected systems.

1. Entry occurs through a low-privilege authenticated foothold in the n8n workflow environment, where the attacker can reach the vulnerable code-execution path.
2. Credential access follows once sandbox escape exposes the process context and lets the attacker read stored secrets, tokens, and configuration data.
3. Escalation happens when the attacker uses that access to modify workflows or database state and gain broader administrative control over the automation plane.
4. Impact is organization-wide compromise of downstream SaaS, cloud, and internal services through trusted automations that now run under attacker influence.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Snowflake breach — Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

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

NHI Mgmt Group analysis

Workflow automation has become an identity concentration point, not a neutral integration layer. When a platform like n8n holds long-lived credentials and executes trusted actions across SaaS, cloud, and internal systems, compromise of the platform becomes compromise of the trust fabric itself. That shifts the problem from application hardening to identity blast-radius control. Practitioners should treat orchestration engines as privileged non-human identity surfaces, not as ordinary apps.

Blocklist-based sandboxing is an architectural assumption, not a durable control. The assumption was designed for environments where dangerous behaviour can be enumerated ahead of time. That assumption fails when the runtime still exposes alternate capability paths, because the attacker only needs one bypass to recover the underlying operating-system primitive. The implication is that security teams must stop trusting symbol-level denial as a containment model for untrusted code.

Credential concentration inside workflow engines creates a single compromise path to many downstream systems. n8n’s role in automating business workflows means it often carries credentials that should never be reachable from code execution contexts. This is a classic NHI governance failure: execution authority and secret access live too close together. Practitioners should re-evaluate whether automation platforms are being granted more trust than the systems they orchestrate.

Post-auth RCE in automation tooling is a governance problem because the platform already encodes administrative delegation. In identity terms, the attacker is not just stealing a session. They are inheriting a delegated trust relationship that was built for convenience, not containment. The field should read this as a signal that workflow platforms need explicit privilege segmentation, lifecycle control, and evidence-based trust boundaries.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably map the identities tied to automation risk.
• That visibility gap is why the next step is not just secret cleanup, but building lifecycle control around the identities behind workflow engines, as outlined in Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Automation platforms are becoming identity brokers, not just integration glue. When code execution, secret storage, and downstream orchestration share the same trust boundary, the platform can function as a control point for the whole environment. That means NHI programmes need to track orchestrators alongside service accounts and API keys, not after them.

Workflow escape risk is really lifecycle risk. If the platform can hold credentials longer than the business process that created them, the exposure window keeps growing. Teams should watch for credentials that persist across workflow changes, owner changes, and decommissioning events, because those are the conditions that turn automation into durable attack surface.

The governance gap is wider than a single vulnerable feature. A platform that can run custom code and access secrets creates an implicit privilege inheritance model, so security teams should evaluate whether their controls assume the runtime is trustworthy when it should be treated as hostile.

For practitioners

• Separate workflow authoring from secret access Ensure users who can edit workflows cannot directly read the credentials, tokens, or database state that those workflows use. Split authoring, execution, and administrative privileges into distinct roles with separate approval paths.
• Reduce the privilege radius of automation runtimes Run code-execution features in isolated environments that cannot reach host processes, mounted databases, or shared secret stores. Assume any reachable capability can be abused if the runtime exposes an alternate execution path.
• Inventory long-lived credentials tied to automation platforms Map every API key, OAuth token, database password, and service account used by workflow engines, then classify each by downstream blast radius. Prioritise the credentials that can change identity state or modify automations.
• Reassess admin boundaries around orchestrators Treat the platform administrator as a high-risk identity and review whether database access, workflow modification, and secret retrieval can be combined by the same account. Remove any standing path that lets code execution become administrative control.

Key takeaways

• A sandbox escape in a workflow engine is an identity event because the platform often holds the credentials and authority to act across many systems.
• The scale of risk comes from trust concentration, not just from the code-execution bug, because one compromise can expose workflows, secrets, and downstream integrations.
• The limiting control is architectural isolation, plus tighter separation between authoring, execution, and secret access in automation platforms.

Key terms

• Automation control plane: The central system that coordinates actions across other tools, services, and data stores. In practice, it becomes a high-trust orchestration layer that can hold credentials and issue privileged requests, which means compromise of the plane can cascade into many downstream systems.
• Sandbox escape: A breakout from a restricted execution environment into a broader runtime context. In security terms, it is dangerous because the code gains access to capabilities that the sandbox was meant to withhold, such as process execution, file access, or secrets held by the host.
• 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.
• Workflow-authoring privilege: The permission to create or modify automations that run with organisational trust. For platforms that handle secrets or identity actions, this is a sensitive non-human identity control because authoring can become indirect access to downstream systems if boundaries are too loose.

Deepen your knowledge

Workflow platform isolation and NHI blast-radius control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing automation platforms that hold secrets and execute trusted actions, it is worth exploring.

This post draws on content published by Cyera: N8Scape (Pyodide sandbox escape), a critical post-auth RCE in n8n (CVE-2025-68668). Read the original.