n8n sandbox bypass exposes workflow servers to code execution

At a glance

What this is: This is a critical n8n sandbox-bypass vulnerability that can let authenticated users execute arbitrary commands on self-hosted workflow servers.

Why it matters: It matters because workflow automation platforms often hold broad credentials and connect to many systems, so a single application flaw can become an identity and access problem across NHI, human, and platform-admin access.

By the numbers:

• CVE-2026-1470 affects n8n 1.x versions before 1.123.17, 2.4.x before 2.4.5, and 2.5.x before 2.5.1.

👉 Read Orca Security's analysis of the n8n sandbox bypass and patch scope

Context

n8n is a workflow automation platform that sits between users, APIs, secrets, and downstream systems. When a sandbox designed to constrain user-supplied JavaScript fails, the problem is not limited to one application server. It becomes a governance issue because workflow engines often concentrate API tokens, database credentials, cloud secrets, and OAuth grants in a single execution path.

For IAM teams, the relevant question is not only whether the platform is patched. It is whether workflow editors, runtime permissions, and exposed integration points are treated as part of the identity attack surface. In practice, a compromise of the workflow layer can turn delegated access into broad downstream reach very quickly, especially in self-hosted deployments.

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 automation platforms create outsized access risk?

A: They often concentrate credentials for many connected systems in one place. That means a single flaw can expose API tokens, database access, cloud secrets, and OAuth grants instead of just one application. The risk grows with every integration added to the automation layer, so the architecture matters as much as the vulnerability.

Q: How should security teams limit exposure from code-bearing workflows?

A: Separate workflow authoring from production secret access, and treat workflow-editing permissions as privileged. Where possible, use dedicated low-trust service identities for execution, remove unnecessary secrets from the automation runtime, and keep the platform off the public internet unless there is a strong operational need.

Q: Who should own remediation when a workflow platform flaw exposes secrets?

A: Ownership should sit across application security, IAM, and platform operations. The patch is the starting point, but the accountable teams also need to review who can edit workflows, which credentials the runtime can reach, and whether connected systems can be segmented so one platform defect does not become a broad access event.

Technical breakdown

How the JavaScript sandbox bypass works

n8n allows JavaScript expressions inside workflows and tries to stop dangerous code by parsing expressions into an abstract syntax tree, or AST. The sandbox blocks access to constructor when it appears as a property, because reaching the Function constructor can create arbitrary code. The flaw appears because the block only applies in one syntactic form. By using the deprecated with statement, an attacker can make constructor resolve to Function without tripping the property-based check, which defeats the sandbox and leads to code execution on the server.

Practical implication: treat expression engines and sandboxed code paths as executable attack surfaces, not just feature flags.

Why authenticated workflow editing becomes a privilege boundary

The exploit does not require anonymous access. It requires authentication and the ability to create or edit workflows, which means the attack boundary sits at the workflow authoring role rather than the network edge. That matters because many organisations grant workflow access to multiple internal users or teams, and some deployments are internet-facing. Once a user can shape execution logic, the platform can be turned from a business automation layer into a command execution layer with whatever trust and reach the instance already holds.

Practical implication: map workflow-editing permissions to privileged access controls and review who can author code-bearing workflows.

Why automation hubs amplify blast radius

Automation platforms are not just applications. They are orchestration points that often store or broker secrets for other systems, which gives them an outsized blast radius. If an attacker gains code execution inside the platform, they may be able to pivot into connected services through cached credentials, tokens, or service integrations. That is why a sandbox failure in a workflow engine should be treated as a concentration-risk event, not only a software defect. The security issue scales with the number and sensitivity of integrations the platform touches.

Practical implication: inventory downstream integrations and reduce the number of high-trust secrets available to the workflow runtime.

Threat narrative

Attacker objective: The attacker aims to turn a trusted workflow platform into a foothold for server control and downstream credential exposure.

1. Entry begins when an authenticated user with workflow-editing rights submits crafted JavaScript into a workflow expression field.
2. Credential access is not the initial step here because the exploit instead bypasses the sandbox and converts the workflow engine into arbitrary code execution on the server.
3. Impact follows through server-level command execution, which can expose platform-held secrets and expand access to connected systems behind the automation hub.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Sandboxing alone is not an identity control. The flaw shows that code-constrained workflow editors still become high-trust execution environments when they hold secrets and broker access. Static sandbox checks can fail on syntax rather than intent, which means the platform inherits the privileges of every connected system. Practitioners should treat workflow authoring as a privileged identity function, not a low-risk automation task.

Workflow engines create identity concentration risk. A single automation hub often aggregates API tokens, database credentials, cloud access, and OAuth grants across many services. That concentration turns one sandbox bypass into a multi-system exposure path. The governance lesson is that blast radius is determined by what the workflow runtime can reach, not just by the CVSS score of the application flaw.

Least privilege has to be expressed at the orchestration layer. If workflow editors can both define logic and touch high-value secrets, the access model is already too broad. This vulnerability shows that authoring permissions, runtime permissions, and secret access should not be bundled together by default. Practitioners need to separate who can build workflows from what those workflows can invoke.

Code-evaluating platforms sit at the boundary between application security and IAM. When a product evaluates user-supplied JavaScript, the resulting risk is not only code injection. It is delegated authority expanding through an identity-rich execution context. That is why organisations need a governance model that covers workflow editors, secret scope, and downstream entitlement inheritance together.

Runtime trust debt is the hidden problem this class of bug exposes: the more a workflow platform accumulates secrets and integrations, the more one defect can multiply into many access paths. That debt is paid only when the platform’s trust assumptions are reduced, not when the next patch is applied. The practical conclusion is to re-evaluate how much authority the automation layer truly needs.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Our research also shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For a broader control baseline, read The 52 NHI breaches Report for recurring failure patterns across exposed credentials and delegated access.

What this signals

Runtime trust debt: workflow platforms accumulate secrets, integrations, and delegated access faster than most security programmes can model them. When a sandbox bypass turns authoring into execution, the issue is not just code safety. It is whether the organisation has separated workflow build rights, runtime rights, and secret scope well enough to stop one defect from becoming an access event.

With 97% of NHIs carrying excessive privileges, the automation layer is rarely the only thing at risk. The same entitlement sprawl that affects service accounts also shows up in orchestration platforms, where long-lived credentials and broad connector permissions magnify the blast radius of a single compromise.

Teams should treat workflow engines as identity-heavy control points, not generic application infrastructure. That means reviewing how many systems the platform can reach, how secrets are provisioned into the runtime, and whether a compromise would let an attacker move from authoring access into downstream service identities.

For practitioners

• Patch vulnerable n8n deployments immediately Move self-hosted instances to n8n 1.123.17+, 2.4.5+, or 2.5.1+ and verify that the patched build is the one actually running in production.
• Restrict workflow editing to trusted operators Limit create and edit permissions to a small group, then review whether those users also have indirect access to secrets or production-integrated workflows.
• Remove internet exposure from self-hosted instances Place the workflow server behind network controls and avoid exposing authoring interfaces directly to the internet, especially where the platform brokers production credentials.
• Reduce the secrets available to the runtime Separate build-time, edit-time, and execution-time credentials so the automation engine does not hold more sensitive access than each workflow truly needs.

Key takeaways

• This vulnerability shows that a sandbox bypass in a workflow engine can become an identity problem the moment the platform holds secrets and delegated access.
• The scale of the risk comes from concentration, because one self-hosted automation server may broker credentials for many connected systems.
• The control that matters most is separating workflow editing rights from runtime secrets and production reach, then removing unnecessary internet exposure.

Key terms

• Workflow automation platform: A workflow automation platform connects services and triggers actions across systems using shared logic and credentials. In security terms, it often becomes a control point that can reach many downstream identities and data sources, so compromise of the platform can create disproportionate access risk.
• JavaScript sandbox: A JavaScript sandbox is a constrained execution environment intended to prevent untrusted code from accessing dangerous objects or server functions. In practice, it is only as strong as the assumptions in its parser, its syntax checks, and the runtime paths it actually blocks.
• Workflow editing privilege: Workflow editing privilege is the ability to create or modify automation logic inside a platform. For identity governance, it should be treated as privileged access when editing rights can influence server execution, call sensitive integrations, or expose credentials held by the runtime.
• Runtime trust debt: Runtime trust debt is the accumulated security exposure created when an orchestration layer is given more secrets, integrations, and authority than it truly needs. The more trust the runtime absorbs, the more damaging a single flaw becomes when it is exploited.

Deepen your knowledge

Workflow automation platforms and delegated access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance around self-hosted automation servers, it is worth exploring.

This post draws on content published by Orca Security: analysis of CVE-2026-1470 affecting n8n. Read the original.