TL;DR: A critical n8n flaw, CVE-2025-68613 with CVSS 9.9, lets authenticated workflow editors inject expressions that escape sandboxing and execute arbitrary code on the host, according to Orca Security. In practice, workflow automation platforms inherit host-level blast radius when expression evaluation is not tightly isolated, so patching and exposure review cannot wait.
At a glance
What this is: This is a critical n8n workflow automation vulnerability where expression injection can break out of sandboxing and execute code on the underlying server.
Why it matters: It matters because workflow editors often hold enough trust to create business logic, and in self-hosted automation platforms that trust can become host-level compromise if expression evaluation is not properly isolated.
By the numbers:
- CVE-2025-68613 carries a CVSS score of 9.9/10.0, according to Orca Security.
Context
n8n expression injection is a workflow security problem, not just a bug in syntax handling. When user-supplied expressions are evaluated inside a workflow engine, the boundary between configuration and execution becomes a trust boundary that must be enforced as tightly as code execution itself.
Orca Security reports that the issue affects self-hosted n8n deployments and embedded automation environments where interactive workflow editing is enabled. For identity and access teams, the important question is not whether the editor is authenticated, but whether that authenticated role has been allowed to cross from workflow authoring into host execution.
The practical governance issue is that workflow platforms often inherit the privileges of the process running them. If expression evaluation can escape its intended context, the workflow editor becomes an indirect route to OS-level command execution, data access, and infrastructure pivoting.
Key questions
Q: What breaks when workflow expressions can escape sandboxing?
A: The workflow engine stops being a safe configuration layer and becomes a code execution surface. In practice, a malicious expression can move from user-supplied workflow content into host commands, which means the automation platform can no longer be trusted to contain runtime effects inside the intended workflow boundary.
Q: Why do authenticated workflow editors still create serious risk?
A: Authentication does not equal safety when the platform can execute code on the host. In that setup, a trusted editor can abuse the expression engine to run commands, access secrets, or alter automation logic. Risk rises further in self-hosted and multi-tenant environments where the workflow process already has broad file, network, or integration access.
Q: How should security teams prioritise remediation for exposed automation platforms?
A: Start with internet-facing or multi-tenant instances that process sensitive data or connect to privileged internal systems. Those deployments have the largest blast radius, so they create the fastest path from a workflow bug to operational disruption or broader compromise.
Q: What does a workflow engine compromise mean for surrounding infrastructure?
A: It means the attacker may inherit the engine’s access to APIs, data, and downstream automation targets. Once arbitrary code runs on the host, the impact can extend well beyond the application into secrets exposure, workflow tampering, and lateral movement.
Technical breakdown
How expression injection turns workflow input into command execution
n8n evaluates workflow expressions to dynamically shape automation logic, but that evaluation must stay inside a sandbox. Expression injection happens when attacker-controlled input is interpreted as executable logic rather than inert configuration. If sandbox isolation is weak, the attacker can force the engine to resolve expressions in ways that reach operating-system functions, turning workflow authoring into a code execution path. The technical failure is not merely unsafe parsing. It is a broken trust boundary between user-supplied workflow content and the runtime context of the n8n process.
Practical implication: Treat workflow expression handling as an execution boundary and verify that untrusted workflow content cannot reach host commands.
Why authenticated editing rights can still produce remote code execution
This vulnerability does not require elevated privileges beyond workflow creation or editing, which makes the attack path especially dangerous in collaboration-heavy automation environments. Authentication proves the editor is known to the system, but it does not prove the editor should inherit the runtime privileges of the automation engine. If the application allows an editor to craft expressions that escape the evaluator, the attacker can obtain the same effective power as the n8n process itself. That is a classic privilege amplification problem inside an application workflow layer.
Practical implication: Separate workflow authoring rights from runtime trust assumptions and assume authenticated editors may still be hostile or compromised.
Host blast radius in self-hosted automation platforms
Self-hosted workflow engines often run with access to internal APIs, credentials, files, and downstream automation targets, which means compromise of the engine can become compromise of the environment it orchestrates. Once arbitrary code execution exists on the host, the attacker can read secrets, alter workflows, manipulate outputs, or move laterally into adjacent systems. The issue is therefore larger than one application bug. It exposes the operational reality that automation platforms concentrate trust, and weak isolation can convert a single workflow flaw into broad infrastructure exposure.
Practical implication: Inventory workflow engines as high-blast-radius assets and limit the permissions, network reach, and secret access of the hosting process.
Threat narrative
Attacker objective: The attacker aims to turn a trusted workflow editing role into host-level execution, data exposure, and possible lateral movement into the wider environment.
- Entry occurs when an authenticated workflow editor submits a specially crafted expression through a vulnerable n8n workflow definition.
- The expression escapes the intended sandbox and is evaluated in the context of the n8n process, giving the attacker OS-level command execution on the host.
- The attacker can then access data, alter automation logic, and pivot further into surrounding infrastructure from the compromised automation server.
Breaches seen in the wild
- Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
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 expression evaluation is a privileged execution boundary, not a configuration convenience. When an automation engine accepts user-supplied expressions, it is handling code-like input even if the product UI presents it as workflow editing. The governance mistake is to treat editor authentication as sufficient assurance. Practitioners should treat expression parsing and sandboxing as part of the host attack surface, because once that boundary fails the automation layer becomes an execution layer.
Editor trust does not equal runtime trust. This vulnerability shows that authenticated access to workflow creation can still be enough to trigger remote code execution when evaluation is insufficiently isolated. The deeper lesson is that identity proof at the UI does not justify inheriting process privileges at runtime. That distinction matters for PAM, IGA, and workflow governance alike: the actor is authenticated, but the resulting authority is not automatically safe.
Automation platforms create identity blast radius when they sit close to secrets, APIs, and internal systems. n8n is attractive to attackers precisely because it often sits at the intersection of integration logic and operational trust. Once the engine is compromised, the impact is not limited to the application. The practical conclusion is that workflow platforms should be governed as high-value identity and execution infrastructure, not as ordinary low-risk business tooling.
OS-level command execution through workflow expressions is a control failure in sandbox design. The issue is not simply that a bug exists, but that the evaluation model allowed untrusted input to cross from workflow content into host execution. That should force security teams to reassess the assumption that automation logic can be safely authored by broadly trusted users. In practice, the workflow engine must be treated as part of the privileged software supply chain around identity and access.
Privilege amplification through editable workflows is now a first-class governance problem. The article shows that the real asset is not the workflow definition alone, but the runtime authority attached to the engine that interprets it. That shifts attention from standard patching urgency to control-plane design, because the same trust pattern can recur anywhere user-authored automation is allowed to execute with broad host privileges.
What this signals
Runtime isolation is the control that matters here: workflow systems can only stay safely delegated if user-authored expressions cannot cross into the host execution layer. For practitioners, that means treating expression evaluation as a privileged boundary and testing whether any editor-driven input can alter the runtime outside the intended workflow scope.
High-blast-radius automation deserves separate governance: when a workflow engine sits near secrets, APIs, and internal services, a single sandbox escape can become an environment-wide incident. Security teams should classify these platforms alongside other privileged control-plane assets, not as ordinary business automation.
The immediate signal for identity programmes is that editor authentication is not enough when the editor can indirectly inherit the permissions of the automation process. Access design, runtime hardening, and patch discipline all have to align, or workflow authoring becomes a path to host compromise.
For practitioners
- Patch vulnerable n8n instances immediately Upgrade self-hosted and embedded n8n deployments to 1.120.4, 1.121.1, or 1.122.0 and do not rely on earlier partial mitigations.
- Audit workflow editor access Review who can create or edit workflows, especially where interactive editing is enabled, and reduce that role to the smallest feasible population.
- Constrain the runtime process Run the automation engine with minimal host permissions, narrow filesystem access, and tightly scoped network and secret reach.
- Inventory exposed automation assets Identify internet-facing or multi-tenant n8n deployments first, then map where those instances process sensitive data or hold privileged integrations.
- Validate sandbox isolation Test whether workflow expressions can reach OS-level functions or other unintended execution paths and treat any escape as a release-blocking issue.
Key takeaways
- n8n expression injection shows how a trusted workflow editor can become a host execution path when sandboxing fails.
- The article ties the flaw to full instance takeover, data exposure, and possible lateral movement in self-hosted deployments.
- Patching, reducing editor exposure, and constraining runtime permissions are the controls most likely to limit the impact.
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 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 | Workflow editors can exploit weak execution boundaries through authenticated access. |
| NHI-05 — Overprivileged NHI | Compromise of the n8n process inherits whatever host privileges the engine holds. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Self-hosted and embedded deployments increase impact when the engine is exposed or overconnected. | |
| Recommendation — Review workflow editor trust boundaries and prevent authenticated input from reaching host execution paths. Reduce the permissions of automation engines so runtime compromise cannot expose broad system access. Harden deployment exposure, network paths, and secret access for workflow automation platforms. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centers on credentials and access allowed into a privileged runtime context. |
| Recommendation — Apply authenticator lifecycle controls to the accounts and secrets that administer workflow engines. | ||
| MITRE ATT&CK | TA0002;TA0006;TA0004;TA0040 — Execution; Credential Access; Privilege Escalation; Impact | The exploit chain moves from code execution to data access, privilege gain, and operational impact. |
| Recommendation — Map the exploit path to execution, credential access, escalation, and impact detections in your telemetry. | ||
Key terms
- Expression Injection: Expression injection occurs when attacker-controlled input is interpreted as executable logic inside an application or workflow engine. In automation platforms, that can let a malicious editor break out of the intended data-processing context and reach system functions, command execution, or sensitive environment access.
- Sandboxed Isolation: Sandboxed isolation is the practice of containing execution in a restricted environment that limits network access, data reach, and resource usage. For AI agents, it reduces blast radius by preventing a model or script from freely touching systems outside its approved scope.
- Workflow Engine: A workflow engine is software that automates multi-step tasks across systems by moving data and triggering actions. In NHI governance, it matters because the engine often holds service credentials and can act on behalf of many systems, making it a concentration point for access and blast radius.
- Execution boundary: The point at which an authorised task turns into a real system change, such as writing data, deleting records, spending money, or invoking a downstream tool. In AI governance, controlling the execution boundary matters more than simply approving access, because harm occurs when actions are allowed to complete unchecked.
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 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org