Notifications
Clear all
Topic starter
10/06/2026 11:48 pm
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.
NHIMG editorial — based on content published by Pillar Security: n8n sandbox escape and complete server takeover through critical vulnerabilities
By the numbers:
- CVSS 3.1 Score: 10.0 Critical, CVE-2026-25049
Questions worth separating out
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.
Q: Why do workflow automation platforms create NHI risk when they store secrets?
A: They create NHI risk because the same runtime that executes workflows often also decrypts or handles API keys, OAuth tokens, and cloud credentials.
Q: How do security teams know whether sandbox controls are actually working?
A: They know by testing for alternate expressions of the same action, not by checking whether one blocked syntax case still fails.
Practitioner guidance
- Map every server-side expression path Inventory where workflow, transformation, or rule engines execute user-controlled logic on the server.
- Separate secret custody from workflow execution Store API keys, OAuth tokens, and cloud credentials outside the runtime that evaluates workflows.
- Test for equivalent-expression bypasses Review sanitisation controls for alternate syntax forms, API calls, and object-manipulation methods that produce the same effect as blocked operations.
What's in the full article
Pillar Security's full research covers the operational detail this post intentionally leaves for the source:
- The exact AST inspection gaps that let template literals and call arguments bypass the sandbox.
- The full five-layer sandbox architecture and where each control failed.
- The patch timeline across the December 21 and December 24 bypasses, including the root-cause fix.
- The post-exploitation paths for self-hosted and cloud deployments, including credential decryption and internal service exposure.
👉 Read Pillar Security's full research on the n8n sandbox escape and credential takeover →
n8n sandbox escape: are your workflow controls built for RCE?
Explore further
12/06/2026 6:10 am
Execution isolation, not sanitisation, is the real trust boundary for workflow platforms: This breach worked because the platform assumed hostile code could be safely filtered after submission. That assumption fails when a workflow engine is expected to run arbitrary expressions as part of normal operation. The implication is that identity and secrets governance for automation platforms must start from containment, not pattern-matching.
A few things that frame the scale:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
A question worth separating out:
Q: Who is accountable when a workflow editor can expose stored credentials?
A: Accountability sits with the teams that own the automation platform, the secret store, and the surrounding identity controls. If a workflow editor can reach stored credentials, then access governance, runtime isolation, and secrets management are shared responsibilities, not separate problems. The control failure is architectural, so the accountability model has to be too.
👉 Read our full editorial: n8n sandbox escape shows how workflow automation can become takeover
