TL;DR: CVE-2026-1470 lets authenticated users bypass n8n's JavaScript sandbox and run arbitrary commands on self-hosted workflow servers, according to Orca Security, with affected releases spanning 1.x before 1.123.17, 2.4.x before 2.4.5, and 2.5.x before 2.5.1. Workflow automation platforms become control-plane exposure points when script sandboxing fails.
At a glance
What this is: This is an analysis of CVE-2026-1470 in n8n, where an authenticated user can bypass the JavaScript sandbox and achieve server-side code execution on self-hosted deployments.
Why it matters: It matters because workflow automation servers often hold high-value secrets and broad integrations, so one sandbox failure can expand from app compromise into cross-system access exposure.
By the numbers:
- CVE-2026-1470 carries a CVSS 9.9 severity score.
- All versions of n8n 1.x before 1.123.17 are vulnerable.
Context
n8n is a workflow automation platform that evaluates user-supplied JavaScript inside workflow logic, which makes script isolation part of the security boundary. In this case, the boundary failed: an authenticated user could bypass the sandbox and execute arbitrary commands on the server.
For identity and access teams, the important issue is not only the vulnerability itself but the role the platform plays in the environment. Workflow engines frequently hold API tokens, database credentials, cloud secrets, and OAuth tokens, so compromise can expose multiple downstream systems at once.
The affected exposure is concentrated in self-hosted deployments, where local privilege, workflow-editing rights, and internet reachability can combine into a control-plane problem rather than a single-application defect.
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 does code execution in a workflow server create outsized risk?
A: Because workflow servers often carry many delegated secrets and service connections in one place. If an attacker can execute code on the host, they may reach downstream systems that trust the platform, including SaaS apps, databases, and cloud services. The risk comes from accumulated trust and broad integration scope, not from the server alone.
Q: What are the signs that workflow-editor permissions are too broad?
A: A warning sign is when many users can edit workflows even though the platform stores production secrets or reaches critical systems. Another sign is when editing rights are bundled with administrative access by default. If workflow authors can touch code-bearing logic without tight review, the platform is being governed as convenience tooling rather than privileged infrastructure.
Q: How should teams respond when a self-hosted workflow platform becomes internet-facing?
A: They should re-evaluate both network exposure and authoring rights at the same time. Internet reachability expands the value of the target, but the real risk depends on who can edit workflows and what secrets the platform can use. A public interface with broad editor access is a materially different risk posture from a tightly segmented internal deployment.
Technical breakdown
How the JavaScript sandbox was bypassed
n8n relies on a JavaScript sandbox to evaluate expressions safely inside workflows. The sandbox parses code into an abstract syntax tree and blocks dangerous constructs, including access to constructor when it appears as a property reference. The bypass works because JavaScript name resolution can be redirected through the with statement, letting constructor resolve to the Function constructor without matching the property-access rule. That turns a sandboxed expression into arbitrary code execution on the host. Practical implication: expression filtering alone is not a durable isolation boundary for user-controlled JavaScript.
Practical implication: Treat sandboxed expression engines as hostile execution surfaces and review whether they can escape into host command execution.
Why workflow automation platforms raise the blast radius
Workflow servers are not simple application runtimes. They often sit between many services, carrying API tokens, database credentials, cloud provider secrets, and OAuth tokens used across the automation estate. Once server-side code execution is available, the attacker is no longer limited to the workflow editor. The platform becomes a pivot point into every connected integration that inherits its trust. In governance terms, the problem is concentrated privilege plus broad reach. Practical implication: the risk profile of a workflow engine must be evaluated by its connected identities and secrets, not just by the application tier itself.
Practical implication: Inventory the secrets and delegated trust stored in workflow platforms before assigning them a risk tier.
Why authentication does not make the issue safe
This vulnerability requires authentication, but that does not make it low impact. Many organisations give workflow editing rights to several internal users, contractors, or platform operators, and some deployments are internet-facing. Authenticated code execution inside the workflow plane creates an abuse path that starts with legitimate access and ends with infrastructure control. The key architectural weakness is that workflow authorisation often assumes editors are safe enough to run arbitrary logic, which is a fragile assumption once the editor itself can break containment. Practical implication: role design for workflow editing must assume code execution risk, not just content authoring.
Practical implication: Restrict workflow-editing rights to the smallest possible group and separate editing privilege from broader platform access.
Threat narrative
Attacker objective: The attacker wants server-side code execution that turns workflow access into broader control over the host and the integrations it orchestrates.
- Entry occurs when an authenticated user with workflow-editing access submits a crafted JavaScript expression to n8n.
- Credential access is not the first step here, because the attacker already has legitimate platform access and uses that access to bypass the sandbox boundary.
- Escalation follows when the with statement resolves constructor to the Function constructor, allowing arbitrary code execution on the server.
- Impact occurs when server-side execution is used to reach sensitive workflows, secrets, and connected systems that trust the platform.
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 automation has become a privileged control plane, not a low-risk glue layer. Platforms like n8n often hold the highest-trust credentials in the environment because they connect SaaS, cloud, and data services in one execution path. That makes any sandbox failure more than an application bug. The practical conclusion is that workflow engines must be governed like privileged infrastructure, because their trust footprint is already larger than their user interface suggests.
Sandboxing user-controlled JavaScript is an isolation assumption, not an identity control. The sandbox was designed for code containment, but the attacker used language semantics to break out of it. This is a control-design failure, not a permission-check failure. The lesson for identity programmes is that runtime containment mechanisms must be evaluated as part of the trust boundary, especially when the system can execute user-authored logic.
Least privilege for workflow editors is often under-specified. Organisations routinely treat workflow editing as an administrative convenience rather than a high-risk capability. That assumption fails when editor access can become arbitrary command execution. The implication is that role models for automation platforms need to distinguish between safe configuration changes and code-bearing workflow changes, because those are not the same governance problem.
Orca Security's disclosure shows why secrets concentration and execution concentration should be assessed together. A workflow platform that aggregates API tokens, database credentials, and cloud secrets creates identity blast radius even before a vulnerability is exploited. Once code execution exists, the platform becomes an identity pivot. Practitioners should treat connected credentials, not just the workload itself, as the unit of risk.
Patch urgency is not only about fixing the bug, but about redefining the trust model around self-hosted automation. Self-hosted deployments keep operational control in the tenant's hands, which also means the tenant owns exposure, patch cadence, and editor governance. The stronger conclusion is that workflow automation needs explicit governance thresholds for who may author code, where the server is reachable, and what secrets the platform is allowed to touch.
What this signals
Workflow server privilege is the real issue here: once an automation platform stores cloud credentials, database secrets, and OAuth tokens, its security boundary extends far beyond the application itself. Governance teams should classify these systems as high-blast-radius infrastructure and review them with that assumption in place.
The control lesson is simple. If user-authored expressions can reach host execution, sandboxing is no longer enough to justify broad workflow-editing rights. Security teams should align authorisation, network placement, and secret handling around the possibility that workflow logic can become code execution.
This vulnerability also shows why access review programmes need context about what an identity can touch, not only whether it is authenticated. Workflow editors with the ability to influence production integrations deserve the same scrutiny as other privileged operators.
For practitioners
- Patch vulnerable n8n releases immediately Upgrade self-hosted n8n deployments to 1.123.17+, 2.4.5+, or 2.5.1+ and verify that all nodes run the fixed builds across every environment.
- Reduce workflow-editing privilege Limit workflow creation and editing to trusted users only, and separate workflow authoring from broader administrative access where possible.
- Treat workflow servers as secret-bearing infrastructure Review the API tokens, database credentials, cloud provider secrets, and OAuth tokens stored or reachable through the platform, then assign exposure based on the connected systems they can reach.
- Restrict internet exposure of self-hosted automation Place self-hosted workflow servers behind controlled network access and avoid exposing the editor interface directly to the internet.
Key takeaways
- This n8n issue is best understood as a workflow-platform trust boundary failure, not just a single application flaw.
- The platform becomes more dangerous when it concentrates credentials and integrations, because code execution can reach far beyond the editor.
- The practical response is to patch quickly, narrow workflow-editing access, and govern the server like privileged infrastructure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Authenticated workflow access is the entry condition for the sandbox bypass. |
| NHI-05 — Overprivileged NHI | Workflow servers often hold too much delegated trust and too many connected secrets. | |
| Recommendation — Constrain authenticated workflow editors and treat editor access as a high-risk NHI boundary. Reduce the privilege and secret scope of workflow platforms to limit blast radius. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | The platform's integrations and secret-bearing connections can be abused once code execution exists. |
| Recommendation — Review how automation platforms consume downstream APIs and restrict unsafe trust propagation. | ||
| MITRE ATT&CK | TA0004;TA0008 — Privilege Escalation; Lateral Movement | Sandbox escape enables escalation on the server and movement into connected systems. |
| Recommendation — Map sandbox bypass risk to privilege escalation and lateral movement controls around automation servers. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The platform's secrets and tokens need lifecycle control because compromise can expose them. |
| Recommendation — Apply IA-5 to govern the lifecycle of secrets and authenticators used by workflow platforms. | ||
Key terms
- Workflow Automation: Workflow automation is the use of predefined rules, triggers, and actions to move work through a process without manual handoffs at every step. In identity programmes, it is useful for routing requests, but it does not replace entitlement decisions, revocation, or assurance that access state actually changed.
- 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.
- 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.
- Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org