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.
NHIMG editorial — based on content published by Orca Security covering the n8n CVE-2025-68613 vulnerability: critical expression injection leading to code execution
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.
Questions worth separating out
Q: What breaks when workflow expressions can escape their sandbox?
A: The control boundary breaks first.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Orca Security's full report covers the operational detail this post intentionally leaves for the source:
- Affected version ranges and fixed release mapping for remediation planning
- How the expression evaluation weakness escapes the intended execution context
- Context on exposure conditions in self-hosted and embedded n8n deployments
- Why the Orca platform prioritises vulnerable assets by internet reachability and criticality
👉 Read Orca Security's analysis of the n8n expression injection vulnerability →
n8n expression injection: what it means for workflow security?
Explore further
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.
A few things that frame the scale:
- 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%.
A question worth separating out:
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.
👉 Read our full editorial: n8n expression injection turns workflow editing into code execution