Notifications
Clear all
Topic starter
19/08/2026 3:27 pm
TL;DR: CVE-2026-27577 is a critical n8n code injection flaw that lets an authenticated workflow editor run host commands by escaping the JavaScript sandbox, affecting self-hosted and cloud deployments before 1.123.22, 2.9.3, and 2.10.1, according to CYCOGNITO. The issue shows how routine edit privileges can become host compromise when automation platforms mix orchestration with broad internal access.
NHIMG editorial — based on content published by CYCOGNITO: Sample of assets impacted by n8n RCE vulnerability, identified by the CyCognito Platform
By the numbers:
- Communication Services accounts for 16.1% of observed assets in the sample.
Questions worth separating out
Q: What breaks when workflow editors can reach execution paths in automation platforms?
A: The permission model breaks first, because a user who is only supposed to author workflows can cross into host command execution if the expression runtime is not properly isolated.
Q: Why do workflow automation platforms create such high lateral movement risk?
A: They sit between many internal systems and often hold credentials, API tokens, and service accounts that trust the automation host.
Q: How do security teams know whether automation access is actually contained?
A: Look for three signals: who can edit workflows, which code or expression paths can reach the runtime, and whether the service account can touch systems beyond its intended job.
Practitioner guidance
- Inventory every n8n instance and its exposure path Find self-hosted and cloud instances outside central IT, confirm their network placement, and identify which ones are reachable over the web or through shared ingress points.
- Restrict workflow edit rights to explicitly trusted operators Separate workflow creation from routine user access, and review whether developers, integrators, or business operators can reach code nodes or expression editing functions that can trigger execution paths.
- Reduce the host blast radius of automation services Run n8n under a least-privilege service account, remove direct internet exposure, and limit outbound connectivity so a compromise cannot freely pivot into other internal services.
What's in the full analysis
CYCOGNITO's full research covers the operational detail this post intentionally leaves for the source:
- Version-specific exposure ranges across n8n 1.123.22, 2.0.0 through 2.9.2, and 2.10.0, which helps teams confirm whether they are actually affected.
- Patch and advisory references, including the GitHub Security Advisories tied to the vulnerability cluster, for teams validating remediation.
- Recommended hardening steps for self-hosted deployments, including access restriction, network containment, and service-account minimisation.
- CyCognito Platform coverage notes for organisations that need external exposure mapping and detection support.
👉 Read CYCOGNITO's analysis of the n8n RCE vulnerability and exposed assets →
n8n sandbox escape risk: what IAM and platform teams need to know?
Explore further
19/08/2026 4:11 pm
Routine editor access is not a low-risk permission when the runtime can cross the sandbox boundary. This vulnerability is not about a rare admin mistake. It shows that application platforms with expression engines can turn normal authoring rights into execution rights if the interpreter is not tightly isolated. For identity programmes, the lesson is that access review must consider what a permission can do at runtime, not only what the label says on paper. The control question is whether the role can reach an execution surface, not whether it looks privileged in the catalogue.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs , Key Challenges and Risks.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Should organisations treat automation platforms as identity-governed assets?
A: Yes, because they often mediate access to credentials, APIs, and internal systems in the same way a workload identity does. The practical question is not whether the platform is a user, but whether it can act with the power of one. Once that is true, access review, offboarding, and secret scoping become identity controls, not just infrastructure tasks.
👉 Read our full editorial: n8n RCE exposes a recurring sandbox failure in workflow automation
