Topic starter
07/06/2026 8:14 pm
TL;DR: CVE-2025-68668 in n8n allows post-auth remote code execution through Pyodide sandbox escapes, with the platform’s own automation role turning a single foothold into access to secrets, workflows, and connected systems, according to Cyera Research Labs. The real issue is not just patching one bug, but recognising that workflow engines can become control planes with far wider blast radius than teams assume.
Editorial analysis by NHI Mgmt Group, based on content published by Cyera: “N8Scape (Pyodide sandbox escape): 9.9 Critical Post-Auth RCE in n8n (CVE-2025-68668)”.
By the numbers:
- CVE-2025-68668 in n8n has a CVSS score of 9.9 and enables post-auth remote code execution through a Pyodide sandbox escape.
- Cyera says its previous n8n disclosure, Ni8mare, was an unauthenticated remote code execution vulnerability with a CVSS score of 10.0.
- Cyera notes that n8n’s public workflow gallery contains 7,600+ published workflows.
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.
Q: Why do workflow engines create such a large blast radius for attackers?
A: Workflow engines connect many systems through trusted credentials and automation logic, so a compromise can expose multiple NHIs at once.
Q: What are the signs that a workflow platform should be treated as a control plane?
A: Look for central orchestration of identity, data, and infrastructure actions; persistent secrets storage; and workflows that execute trusted business processes across multiple systems.
Practitioner guidance
- Model workflow platforms as privileged control planes Map every n8n or similar workflow engine to the systems, identities, and secrets it can reach.
- Replace function blocklists with capability isolation Review any code-execution feature that relies on blocking specific calls such as process spawning or JavaScript bridges.
- Inventory long-lived credentials inside automation runtimes Identify API keys, OAuth tokens, database passwords, and similar secrets stored or reachable from workflow engines.
Bottom line: The core risk is delegated trust concentration, where a workflow engine can reach far more than its user interface suggests.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
07/06/2026 10:04 pm
Workflow engines have become delegated control planes, not just task runners. When one platform can orchestrate cloud, SaaS, database, and identity actions, the security model must reflect concentrated authority rather than isolated app access. That changes how teams assess blast radius, because compromise is measured by the downstream trust the platform already holds. The practitioner conclusion is that automation platforms belong in the privileged tier of identity governance.
A question worth separating out:
Q: Should teams disable code execution or redesign the execution model in workflow platforms?
A: If code execution is required, the safer path is redesigning the execution model so untrusted code runs in a truly isolated runtime with no direct access to privileged process capabilities. Disabling the feature is a temporary containment measure, but capability removal is the stronger governance choice when the platform handles sensitive integrations.
👉 Read our full editorial: n8n sandbox escape shows the blast radius of workflow control planes
This post was modified 3 days ago by NHI Mgmt Group