TL;DR: Three critical n8n vulnerabilities allow unauthenticated and authenticated remote code execution through webhook parsing, expression evaluation, and unsafe workflow execution, according to CYCOGNITO. The pattern matters because workflow automation often sits near credentials and internal systems, so one exposed instance can become a broader access-path problem.
At a glance
What this is: CYCOGNITO says three critical n8n flaws can lead to remote code execution through webhook parsing, expression evaluation, and unsafe workflow execution.
Why it matters: This matters to IAM and security teams because exposed automation platforms often hold sensitive integrations, internal reach, and privileges that widen the blast radius of compromise.
Context
n8n is a workflow automation platform that connects services and orchestrates operational tasks, which makes it a control point rather than a simple application. When an automation server can parse attacker-controlled webhooks or evaluate workflow expressions unsafely, the issue is not only code execution but also the possibility of pivoting into credentials, internal systems, and business workflows. In environments where automation is deployed outside central inventories, identity and access assumptions are often weaker than the platform's reach.
The article describes a classic governance gap for automation infrastructure: teams often secure the workflow logic itself but not the execution boundary around it. That boundary matters because n8n instances may be self-hosted or cloud-hosted, externally reachable, and allowed to touch sensitive API keys or internal integrations. For IAM, PAM, and NHI programmes, this is a reminder that automation runners can behave like high-trust service identities even when they are treated as ordinary apps.
Key questions
Q: What breaks when n8n webhook exposure is not properly contained?
A: A public webhook can become a direct path into server-side execution when parsing is unsafe. The failure is not only technical exposure but governance collapse, because the platform may then act with access to internal systems, APIs, and secrets that were never meant to be reachable from the internet.
Q: Why do workflow automation platforms create such a large blast radius when RCE is possible?
A: They often run close to service credentials, internal APIs, and business integrations, so code execution inside the platform can cascade into other systems. The risk grows when the platform's runtime permissions are broader than the task itself, which turns one compromised workflow server into a launch point for deeper access.
Q: What are the signs that workflow-editor permissions are too broad?
A: A warning sign is when many users can edit workflows even though the platform stores production secrets or reaches critical systems. Another sign is when editing rights are bundled with administrative access by default. If workflow authors can touch code-bearing logic without tight review, the platform is being governed as convenience tooling rather than privileged infrastructure.
Q: How should security teams respond when an automation platform may be compromised?
A: Assume exposure, take the service offline if possible, and rotate every credential the platform used or stored. Then identify the workflows, identities, and downstream systems that could have been reached. Response needs to cover both the application and the NHI estate it brokered, because the access path matters as much as the exploit.
Technical breakdown
Webhook parsing as an unauthenticated execution path
Webhook endpoints are designed to accept external requests and trigger automated actions, which makes request parsing part of the trust boundary. If parsing logic handles crafted input unsafely, an attacker can move from a public endpoint into server-side code execution without first obtaining credentials. In this case, the vulnerability shows how an integration surface becomes a runtime control surface when input validation, request normalisation, and execution separation are weak. For workflow platforms, the risk is not the webhook itself but the fact that it can bridge internet exposure to privileged internal activity.
Practical implication: Treat exposed webhook handlers as attack surfaces that need isolation, not just access control.
Expression evaluation and code injection in workflow logic
Workflow engines often support expressions so users can transform data, route tasks, or call downstream services. That flexibility becomes dangerous when expression evaluation can be influenced by a user who is authenticated but not fully trusted, because the engine may interpret attacker-controlled content as executable logic. In practical terms, this is a separation-of-duties problem inside the platform: the same interface that builds automation can also become a code execution path if permissions are too broad and input boundaries are thin. The governance lesson is that authenticated access does not equal safe execution authority.
Practical implication: Limit who can author workflows and review any feature that evaluates user-supplied expressions at runtime.
Unsafe workflow execution and over-trusted automation identities
Automation platforms typically run with access to internal APIs, secrets stores, and business systems, so successful execution inside the platform can quickly turn into broader compromise. Unsafe workflow execution paths are especially risky when the platform allows users to trigger actions that inherit privileged runtime context without sufficient containment. That makes the workflow engine behave like a high-trust service identity, even though the human operator may only have limited authoring rights. For identity security teams, the important issue is not just privilege assignment but whether the platform can contain the privileges it borrows during execution.
Practical implication: Constrain the runtime permissions of automation workers and separate authoring rights from execution rights.
Threat narrative
Attacker objective: The attacker wants arbitrary code execution inside a workflow automation platform that already has trusted access to internal systems and sensitive integrations.
- Entry occurs through an externally exposed webhook endpoint or through an authenticated workflow authoring path.
- Credential access is not always required first because the unauthenticated flaw can place the attacker directly into server-side execution.
- Escalation follows when malicious expressions or unsafe execution paths run code inside the automation platform's runtime context.
- Impact is the ability to control the n8n instance and potentially reach connected internal systems, credentials, and integrations.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
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
Automation platforms are high-trust runtime systems, not low-risk glue code. n8n sits between external triggers and internal business systems, so an RCE in the platform is more than an application bug. It can become a privilege boundary failure because the platform is often allowed to touch credentials, APIs, and downstream workflows. Practitioners should treat workflow orchestration as part of the identity attack surface, not just the application estate.
The named concept here is workflow trust inversion: the platform that is supposed to mediate access starts acting as the most privileged actor in the chain. When webhook parsing or expression evaluation is exploitable, the trust model is reversed and the automation layer becomes the shortest path to internal reach. That is especially relevant for NHI programmes because orchestration tools frequently handle service credentials and delegated access. The control question is whether execution context is more privileged than the task requires.
Authenticated access is not a sufficient safety boundary when the execution engine itself is exposed. The article shows that a legitimate workflow editor can still turn into a code execution source if the platform does not separate authoring from execution authority. That is a reminder for IAM and PAM teams that role design must account for runtime consequences, not only interface permissions. Practitioners should test whether authoring rights can trigger unsafe execution paths.
Discovery matters because automation systems are often under inventoried and over-connected. The article's emphasis on self-hosted and cloud-hosted deployments is important: if teams do not know where n8n is running, they cannot patch, restrict, or monitor it reliably. This is where NHI governance and external attack surface management intersect. The practical conclusion is to manage automation platforms as exposed control-plane assets, not as ordinary internal apps.
What this signals
Workflow orchestration now deserves the same inventory discipline as privileged infrastructure. Many organisations discover automation servers late, after they have already been wired into internal APIs and credential flows. For identity and security teams, the practical shift is to classify these platforms as control-plane assets and bring them into external attack surface management, patch governance, and privileged access review.
Workflow trust inversion is the governance problem this article exposes: the layer designed to connect systems can become the shortest route into them. That means IAM and PAM teams need to review not only who can edit automations, but also what execution context those automations inherit. If the runtime can touch secrets or internal services, compromise of the platform becomes an identity event as much as an application one.
For practitioners
- Inventory every n8n deployment Map self-hosted, cloud-hosted, test, and legacy instances before assuming they are covered by standard application inventory processes.
- Patch to the fixed n8n versions Upgrade vulnerable instances to the vendor's patched releases and treat version checks as a mandatory remediation gate before re-exposure.
- Restrict webhook exposure at the perimeter Reduce internet exposure for webhook endpoints with network controls, reverse proxies, and API gateways where business requirements allow it.
- Separate workflow authoring from execution trust Limit who can create or edit workflows and ensure the runtime account used for execution has only the permissions the task requires.
- Monitor automation activity for abuse patterns Watch for unusual webhook volume, unexpected workflow changes, and abnormal execution behaviour that can indicate attempted code execution.
Key takeaways
- n8n RCE flaws show how workflow automation can turn from orchestration layer into an execution boundary that attackers can cross.
- The main risk is not isolated code execution but the ability to pivot from an automation server into internal systems, APIs, and secrets.
- Teams need inventory, patching, and tighter separation between workflow authoring and runtime privilege before exposed automation systems become a wider access path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001;TA0002;TA0006;TA0008 — Initial Access; Execution; Credential Access; Lateral Movement | The article describes unauthenticated entry, code execution, and pivot potential through automation systems. |
| Recommendation — Map exposed webhook and workflow paths to ATT&CK and hunt for execution abuse across automation assets. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | n8n workflow authoring and runtime access need tighter entitlement boundaries. |
| Recommendation — Apply PR.AA-05 to separate workflow creation rights from runtime permissions. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Automation platforms act like service identities when they authenticate to internal systems. |
| Recommendation — Use IA-9 to govern automation runtimes that authenticate to APIs and internal services. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article recommends limiting who can edit workflows and reducing unnecessary access paths. |
| Recommendation — Use CIS-5 to review who can manage automation accounts and workflow permissions. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Externally exposed webhook and admin interfaces are misconfiguration-sensitive attack surfaces. |
| Recommendation — Apply API8 to harden exposed webhook and administrative interfaces before attackers can abuse them. | ||
Key terms
- Workflow Automation: Workflow automation is the use of predefined rules, triggers, and actions to move work through a process without manual handoffs at every step. In identity programmes, it is useful for routing requests, but it does not replace entitlement decisions, revocation, or assurance that access state actually changed.
- Webhook: An automated HTTP callback that sends event data from one application to another when a trigger occurs. In security terms, a webhook is a machine-to-machine trust path that can carry sensitive data and authorization context without a human login step.
- Expression Evaluation Engine: An expression evaluation engine interprets user-defined logic inside a workflow or application. When that engine can be steered into code execution, a configuration feature becomes an attack surface because trusted users may be able to translate data input into arbitrary system commands.
- Runtime Privilege: Runtime privilege is the effective access an identity has after tools, data sources, and permissions are combined during execution. For AI agents, it can exceed the originally approved scope because the agent may chain actions across systems in ways no single entitlement review reveals.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect delegated access, service credentials, and automation platforms to the controls their programmes need.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org