n8n expression injection turns workflow editing into code execution

At a glance

What this is: Orca Security reports a critical n8n expression-injection vulnerability that can turn workflow editing into host-level code execution.

Why it matters: For IAM, NHI, and platform security teams, this shows how authenticated workflow authorship can become a high-impact control boundary when expression engines lack sandbox isolation.

By the numbers:

• A critical vulnerability, CVE-2025-68613, was disclosed with a CVSS score of 9.9 out of 10.0.
• The flaw affects n8n versions starting from 0.211.0 up to but not including 1.120.4, 1.121.1, and 1.122.0.
• Users should upgrade to 1.120.4, 1.121.1, or 1.122.0 to harden expression evaluation.

👉 Read Orca Security's analysis of the n8n expression injection vulnerability

Context

CVE-2025-68613 shows how workflow automation becomes a security boundary when user-supplied expressions are evaluated inside the orchestration engine. In n8n, the problem is not just code execution in abstract terms. The issue is that workflow authorship can cross into host execution if sandbox isolation is weak.

For IAM and NHI programmes, the lesson is that authenticated editing rights are still privileged rights when the engine can invoke OS-level commands. Self-hosted workflow platforms, embedded automation stacks, and multi-tenant environments need to treat expression evaluation as part of the control plane, not as harmless application logic.

Key questions

Q: What breaks when workflow expressions can escape their sandbox?

A: The control boundary breaks first. A workflow engine that evaluates user-supplied expressions without strong isolation can turn data manipulation into command execution, which means an authenticated editor may reach host-level privilege through what looked like ordinary workflow logic. The real failure is not just insecure input handling. It is the assumption that workflow authorship is separate from execution authority.

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 can security teams reduce the blast radius of automation platforms?

A: Security teams should limit the privileges of the automation runtime, segment downstream credentials, and verify which internal services the process can reach. If the platform is compromised, the impact depends on what the process can touch. Least privilege for the runtime and narrow secret scope are the two controls that most directly shrink the blast radius.

Q: Who is accountable when a workflow platform vulnerability leads to code execution?

A: Accountability sits with the teams that own the platform, the workflow permissions model, and the deployment posture. If the platform is internet-facing, embedded in products, or used by multiple tenants, the governance burden is higher because one vulnerable editor path can expose many systems. Patch ownership, access control, and runtime segmentation all need explicit owners.

Technical breakdown

Expression injection in workflow engines

Workflow engines often let users insert expressions to transform data, branch logic, or call downstream actions. If those expressions are evaluated with inadequate sandboxing, attacker-controlled input can escape the intended interpreter context and reach host functions or command execution paths. In this case, the weakness sits in the boundary between workflow logic and runtime execution. Once that boundary fails, a low-privilege editor can move from manipulating a workflow definition to controlling the process that runs it.

Practical implication: treat expression evaluation as executable input and isolate it with the same care as code execution surfaces.

Why authenticated access still creates high risk

This vulnerability does not require unauthenticated remote access or administrative privileges. That matters because many automation platforms assume that workflow creators are trusted enough to author logic, even if they are not trusted to execute arbitrary OS commands. When the editor role can reach the interpreter layer, the trust model collapses. Authentication reduces exposure but does not eliminate abuse when privilege boundaries are too coarse.

Practical implication: separate workflow authorship rights from any path that can reach system-level execution.

Host takeover and lateral movement after compromise

Once an attacker can execute commands as the n8n process, the impact extends beyond the platform itself. They may read workflow data, steal embedded secrets, alter automation logic, or pivot into adjacent infrastructure where the process has network or file access. In self-hosted deployments, the workflow engine can become a bridge into broader operational systems because it often holds credentials, API tokens, and integration paths that were never meant to be exposed to a malicious editor.

Practical implication: inventory what secrets and network paths the automation runtime can reach before assuming the blast radius is limited.

Threat narrative

Attacker objective: The attacker aims to convert trusted workflow editing into remote code execution and broader environment compromise.

1. Entry occurs through authenticated workflow creation or editing inside a vulnerable n8n instance, where the attacker can submit specially crafted expressions.
2. Escalation happens when the expression evaluator escapes its intended sandbox and executes OS-level commands with the privileges of the n8n process.
3. Impact follows as the attacker gains host-level control, with opportunities to exfiltrate workflow data, manipulate automation logic, and pivot into surrounding infrastructure.

Breaches seen in the wild

• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Expression evaluation is now a privileged execution surface, not a convenience feature. Workflow editors are often granted broad trust because their actions appear limited to business logic. This vulnerability shows that trust is misplaced when the expression engine can cross into host execution. The practical conclusion is that automation platforms must be governed as high-risk runtime environments, not as low-risk application builders.

Authenticated workflow creation is not a low-risk identity state when the engine can execute code. The usual assumption is that logged-in authors are entitled to define logic, while the platform safely contains that logic. That assumption fails here because the editor can steer the platform into OS-level command execution. Expression trust boundary collapse: the boundary between data transformation and code execution has failed, so practitioners must rethink who is allowed to author and run workflows in the same environment.

Automation platforms can become credential amplifiers when runtime access is broader than intended. Once the process can reach secrets, APIs, and internal services, compromise of the workflow engine turns into a supply path for lateral movement. That makes runtime reachability and secret scope the decisive governance questions, not just patch status. Practitioners should map every downstream privilege that workflow execution can touch.

Partial mitigations are a warning sign that the control model was patched, not corrected. The article notes earlier fixes did not fully address the underlying issue, which is a familiar pattern in expression-engine vulnerabilities. The lesson for the field is that hardening needs to validate execution boundaries, not merely reduce exploit convenience. Security teams should treat any previously mitigated automation engine as re-exposed until the full fixed release is deployed.

From our research:

• 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37%.
• That confidence gap is why practitioners should also review the Guide to the Secret Sprawl Challenge when automation platforms store credentials, tokens, and API keys in workflow paths.

What this signals

Expression trust boundary collapse: workflow engines that evaluate user input inside the control plane create a governance problem that looks like appsec but behaves like privileged execution. For teams running automation at scale, the question is no longer whether the platform can edit workflows safely. It is whether the runtime can ever be trusted to contain attacker-authored logic once that logic can reach host commands and internal secrets.

The programme signal is clear for self-hosted automation and embedded workflow products. If the platform can access credentials, internal APIs, or file systems, a single expression flaw can turn a workflow editor into a lateral movement path. Security teams should therefore classify automation runtimes alongside other high-value NHI surfaces and review them with the same entitlement and secret-scope discipline.

This is also a reminder that vulnerable workflow engines belong in the same operational review cycle as service accounts and API keys, not in a separate application bucket. When authoring rights can trigger execution, access reviews need to consider both who can edit the workflow and what the runtime can do on their behalf.

For practitioners

• Upgrade vulnerable n8n instances immediately Move affected environments to 1.120.4, 1.121.1, or 1.122.0 and verify every self-hosted or embedded deployment that uses the core workflow engine.
• Review who can create or edit workflows Restrict interactive workflow editing to the smallest possible set of trusted operators and separate authoring rights from production execution paths.
• Map the runtime blast radius of automation hosts Inventory secrets, network reach, file access, and downstream API permissions available to the n8n process so you know what a successful escape can touch.
• Validate that sandboxing actually blocks command execution Test expression handling in a controlled environment and confirm that user-supplied inputs cannot reach OS-level commands or escape interpreter boundaries.
• Recheck previously mitigated deployments Reassess any environment that relied on partial mitigations, because earlier fixes did not fully address the underlying sandbox escape issue.

Key takeaways

• The n8n flaw shows that workflow editing can become code execution when expression evaluation is not properly sandboxed.
• The headline risk is host takeover, but the practical blast radius depends on what the workflow process can reach after compromise.
• Immediate patching, tighter authoring rights, and runtime privilege review are the controls that matter most for exposed automation platforms.

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.
• Sandbox Isolation: Sandbox isolation is the containment layer that limits what untrusted code or expressions can do when they are evaluated. In workflow systems, it should keep user-authored logic inside a narrow execution boundary so it cannot call host commands, access files, or interact with unintended internal resources.
• Runtime Blast Radius: Runtime blast radius is the set of systems, secrets, and data a compromised process can reach at execution time. For automation engines, it is often larger than teams expect because the platform may already hold tokens, API keys, and network paths needed to run workflows.

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.

This post draws on content published by Orca Security covering the n8n CVE-2025-68613 vulnerability: critical expression injection leading to code execution. Read the original.