TL;DR: Two critical n8n sandbox escapes let any authenticated workflow editor execute commands, read environment variables, decrypt stored credentials, and potentially reach cloud accounts and shared services, including on n8n Cloud, according to Pillar Security researchers. The incident shows that workflow automation platforms executing user code need execution isolation, not just sanitization, because the control plane can become the blast radius.
At a glance
What this is: Pillar Security found critical n8n sandbox escapes that allowed authenticated workflow users to achieve full server control and credential exposure in both self-hosted and cloud deployments.
Why it matters: IAM, PAM, and NHI teams need to treat workflow automation runtimes as privileged execution environments because a single editor account can become a path to secrets, cloud access, and multi-tenant blast radius.
By the numbers:
- The vulnerabilities carried a CVSS 3.1 score of 10.0 Critical and were tracked as CVE-2026-25049.
Context
n8n is a workflow automation platform that evaluates user-provided JavaScript-like expressions on the server side, so its sandbox becomes part of the trust boundary rather than a simple input filter. In this case, Pillar Security showed that the control failed in a place many teams do not treat as privileged code execution, which is exactly why workflow automation can become a takeover path.
The identity governance problem is not limited to the editor account itself. Once the runtime is compromised, stored secrets, connected cloud accounts, and shared internal services become reachable through the automation plane, which means access control has to be designed around execution isolation and credential containment, not just workflow permissions.
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 sandbox escapes in automation platforms create such a large identity risk?
A: Because the platform often stores credentials for cloud, API, and database access in the same environment that executes workflows. If an attacker reaches the runtime, they may inherit the platform’s own secret access and turn one editor account into a much broader compromise chain.
Q: What are the signs that sandboxing in a data workflow platform is too weak?
A: Look for runtimes that still expose alternate paths to builtins, library loading, or host hooks after the supposed sandbox is applied. If one blocked API is replaced by another route to the same capability, the isolation boundary is brittle. A weak sandbox is one where untrusted formulas can still affect host-level behaviour.
Q: How should teams respond when a workflow automation platform can decrypt stored secrets?
A: Assume the credential boundary has already collapsed and review what the platform can reach with decrypted secrets, including cloud accounts, shared services, and internal registries. The immediate question is not only containment, but whether secret custody and execution now need to be split.
Technical breakdown
How n8n expression sanitization failed at the AST level
n8n’s sandbox relied on parsing and rewriting JavaScript expressions before execution, with denylisted properties and runtime checks intended to block dangerous access. The flaw was structural: different JavaScript syntaxes can express the same operation, but a sanitizer that only inspects some syntax nodes will miss others. Template literals bypassed property checks, and a separate path let Object.defineProperty() write to dangerous properties without triggering the same guardrails. That is a classic abstract syntax tree, or AST, failure mode: the security logic assumed one representation of intent and missed another equivalent one.
Practical implication: inspect the AST for equivalent operations, not just the obvious syntax forms, when user code is expected to run.
Why the sandbox escape became full remote code execution
Once the attacker reached the V8 stack frame hook, the sandbox returned a reference to the real global object outside the restricted context. From there, the runtime exposed Node.js capabilities such as built-in modules and child process execution. That converted a sandbox boundary failure into remote code execution on the n8n server, which is the decisive moment for identity security because the platform’s own execution context becomes the attacker’s authenticated foothold. In workflow platforms, code evaluation and privilege separation are inseparable architectural concerns.
Practical implication: treat any server-side expression engine as a privileged execution surface unless the runtime itself is isolated.
Why stored credentials became the next compromise boundary
n8n encrypts stored secrets with an environment key, so once the attacker could read environment variables, they could recover the N8N_ENCRYPTION_KEY and decrypt credentials in the database. That meant cloud provider keys, API tokens, database passwords, and OAuth secrets were all inside the same blast radius as the sandbox escape. In NHI terms, this is not just credential exposure. It is a privilege amplification chain where one runtime flaw collapses the protection around every non-human identity embedded in the automation platform.
Practical implication: separate secret custody from workflow execution and assume any runtime escape can expose the full NHI credential estate.
Threat narrative
Attacker objective: The attacker objective was to turn workflow-editing access into server takeover and credential theft across connected systems and shared services.
- Entry occurred when an authenticated workflow editor submitted malicious expression content through the normal workflow interface.
- Credential access followed when sandbox bypasses exposed the real Node.js process and the environment key used to protect stored secrets.
- Escalation happened as the attacker decrypted credentials, reached connected cloud accounts, and accessed internal services in the cloud deployment.
- Impact was complete server takeover, secret exposure, and potential platform-wide compromise in the shared cloud environment.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
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 control planes now behave like privileged execution environments: when a platform evaluates user code on the server, the control plane itself becomes part of the blast radius. That changes the governance model for workflow editors, because editor privilege can translate into runtime privilege without any separate administrative action. Practitioners should treat code-evaluating automation platforms as high-risk execution surfaces, not as ordinary low-code tooling.
Sanitization-based security breaks when the same intent can be expressed through multiple syntax paths: the n8n issue shows that blocklists and AST rewrites are fragile when the runtime is allowed to execute user-supplied logic. The broken premise is that you can safely enumerate all dangerous forms of an operation before execution. That premise fails in dynamic languages, and identity teams should assume the control plane can be subverted through semantic equivalence, not just obvious payloads.
Execution isolation is the named concept that matters here: protecting the workflow editor is not enough if the runtime can still touch the host process, environment keys, and shared services. This is an identity blast radius problem, because one compromised execution context can unlock every stored NHI credential attached to the platform. Practitioners should evaluate whether their automation stack isolates code at the process, container, and secret-boundary level, not merely at the UI layer.
Shared cloud automation creates multi-tenant trust debt: on a managed platform, the compromise of one tenant can expose internal services and widen the path toward other tenants if the underlying isolation model is weak. That is a governance problem as much as a technical one, because tenancy promises are only as strong as the runtime boundary underneath them. Security teams need to re-test vendor claims about tenant separation whenever a platform executes user-provided code.
Non-human identity governance has to move closer to issuance and execution time: when a workflow engine can decrypt and reuse stored credentials, the old assumption that secrets remain protected until a later abuse event no longer holds. That assumption fails because the platform itself becomes the abuse point. Practitioners should therefore review whether NHI credentials live inside an execution domain that can read its own vault.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: Agentic AI Identity Guide
What this signals
Execution isolation has become the dividing line between automation and compromise: workflow platforms that run user logic on the server need boundary controls at the runtime layer, because input sanitization alone cannot contain code that is supposed to execute. That puts agentic workflow governance and NHI custody into the same design problem, especially where the platform stores reusable cloud and API credentials.
The practical programme shift is to review every workflow engine as an identity-bearing execution environment. If the platform can see its own secrets, the blast radius already includes NHI credentials, cloud accounts, and shared services, so governance has to move upstream of the workflow editor.
Identity blast radius: a single sandbox escape can convert one authenticated editor into reach across secrets, tenant services, and downstream infrastructure. That means access reviews for the UI are not enough; teams need evidence that the runtime cannot read the material it protects.
For practitioners
- Harden expression evaluation boundaries Review every workflow platform that evaluates user-supplied logic on the server and confirm that dangerous runtime capabilities are isolated from the execution context, not just filtered at input time.
- Separate secret custody from workflow execution Move high-value credentials out of the same process space that evaluates workflows, and validate that an execution escape cannot read the encryption key used for stored secrets.
- Reassess editor-to-server privilege Treat workflow editor access as a privileged path and map what server-side code execution would expose if an authenticated user could alter expressions or runtime hooks.
- Test tenant isolation under compromise assumptions For managed automation platforms, verify whether one tenant’s compromise can reach shared internal services, metadata endpoints, or cross-tenant data through the automation layer.
Key takeaways
- The core risk is not just bad input handling. It is a workflow engine that can turn an ordinary editor account into server-level execution.
- The article shows that the same escape path exposed environment variables, decrypted credentials, and internal cloud services, which expands the blast radius well beyond the workflow itself.
- The control failure sits at the runtime boundary, so the limiting factor is execution isolation rather than another layer of sanitization.
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 Agentic AI Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The escape exposed stored secrets, API keys, and encryption material inside the automation runtime. |
| NHI-05 — Overprivileged NHI | A workflow editor could reach server-level capabilities far beyond its intended scope. | |
| NHI-07 — Long-Lived Secrets | Decrypted credentials persisted inside the platform and became reachable after runtime compromise. | |
| Recommendation — Audit workflow engines for secret leakage paths and separate secret custody from code execution. Reduce workflow runtime privilege so editor actions cannot translate into server control. Shorten secret lifetime and keep long-lived credentials out of executable workflow contexts. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | User-controlled automation code abused the platform's identity and privilege boundary. |
| Recommendation — Apply identity and privilege abuse controls to any agentic workflow that can execute user logic. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack chain moved from sandbox escape into credential theft and traversal of connected systems. |
| Recommendation — Map the escape path to credential access and lateral movement techniques in detection engineering. | ||
Key terms
- Execution Isolation: Execution isolation is the separation of decision-making, parameter handling, and code execution so that untrusted input cannot directly shape a running command or privileged action. It is stronger than simple sanitisation because it changes where and how the action is allowed to occur.
- 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.
- Inline Sanitization: Inline sanitization cleans content before it is sent, saved, or synchronised into another system. It is a preventive control, not a retrospective cleanup step. For data redaction use cases, inline sanitization helps stop regulated or confidential information from entering support tools, cloud storage, or AI systems in the first place.
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.
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