TL;DR: CVE-2026-72766 in n8n can turn an exposed Send Email node into local file disclosure and server-side request forgery when unauthenticated webhooks, SMTP credentials, and untrusted body fields align, according to CYCOGNITO. The core issue is not just patching a type confusion bug, but eliminating workflow conditions that let automation platforms become credential-rich attack surfaces.
At a glance
What this is: CYCOGNITO says CVE-2026-72766 in n8n can expose local files and trigger SSRF through the Send Email node when specific webhook and input conditions are present.
Why it matters: It matters because self-hosted workflow platforms often store credentials and configuration data, so one misused node can turn automation into a privileged access path for broader compromise.
By the numbers:
- The vulnerability affects n8n versions before 1.123.67, 2.x versions before 2.31.5, and 2.32.x versions before 2.32.1.
Context
n8n file-read risk is a workflow governance problem as much as a software flaw. When automation tools sit between systems and carry SMTP or other credentials, a single parsing mistake can expose files, environment data, and downstream trust boundaries that were never meant to be reachable from a webhook.
The key security issue is that the vulnerable path depends on a live workflow, not just an installed package. That means inventory, workflow design, and input handling matter alongside patching, especially in self-hosted deployments where teams often stand up automation quickly and leave it outside central review.
Key questions
Q: What breaks when a public workflow trigger feeds privileged email handling?
A: The trust boundary breaks. A public trigger can hand attacker-controlled data to a node that can read files or make outbound requests, so the workflow stops behaving like a simple automation and starts acting like a privileged execution path. The practical failure is that the platform no longer preserves the difference between external input and internal control data.
Q: Why does a file-read bug in automation software create broader compromise risk?
A: Because workflow engines often store credentials, environment variables, and integration secrets for many downstream systems. Once an attacker can read host files or trigger SSRF from inside the platform, the impact can extend well beyond the original workflow. The same defect becomes materially more dangerous when the platform sits near other high-value services.
Q: What are the signs that a workflow platform is misconfigured for exposure?
A: Look for unauthenticated webhooks, direct mapping of external input into transport fields, and self-hosted instances that were deployed quickly and never brought into inventory. Those patterns indicate that a workflow can be reached from outside while still holding privileged credentials inside the runtime.
Q: Should teams prioritise webhook restriction before rotating stored secrets?
A: Yes, when the vulnerable workflow is still reachable from the internet. Rotating secrets reduces the value of any exposure, but restricting public reachability removes the active attack path and is often the faster containment step. The best sequence is to cut off external access first, then rotate any credentials stored on the instance.
Technical breakdown
How type confusion in the Send Email node becomes file disclosure
Type confusion happens when software treats one data type as another. In this case, the Send Email node does not enforce that message fields are strings, so a workflow expression can pass a non-string value into Nodemailer. If the mail library interprets that value as a file path or URL, the platform may open a local file or make an outbound request instead of sending plain text. That is why a seemingly small input-handling defect can expose host data and network reachability from inside the automation runtime.
Practical implication: validate field types at workflow boundaries and do not let untrusted expressions reach transport-layer parameters.
Why unauthenticated webhooks change the attack surface
An unauthenticated webhook gives an external caller a way to trigger internal workflow logic without first proving identity to the platform. That does not create the flaw, but it creates the reachability needed to weaponize it. If the workflow then maps webhook content directly into the Send Email body, attacker-controlled input flows into a component that can reinterpret it as a file or URL. In governance terms, the issue is not just exposure of an endpoint. It is the combination of public trigger, privileged node, and untrusted data path.
Practical implication: treat public workflow triggers as trust boundaries and isolate them from any node that can touch files or outbound URLs.
Why workflow automation systems become credential-rich targets
Automation platforms often hold configuration files, environment variables, and stored credentials for many connected services. That makes local file read more valuable here than in a single-purpose application, because one read may expose keys for email, cloud, or business systems the workflow controls. SSRF compounds the risk by allowing requests to originate from inside the network segment where n8n runs. The result is a pivot point from workflow compromise into broader environment reconnaissance or secret theft.
Practical implication: classify workflow engines as high-value credential stores and harden them like other privileged integration layers.
Threat narrative
Attacker objective: The attacker wants to extract host files and secrets, then use the workflow platform as a foothold for deeper internal access.
- Entry occurs when an attacker can reach an unauthenticated webhook attached to an active n8n workflow.
- Credentialed workflow state and direct input mapping let the attacker steer untrusted data into the Send Email node.
- The mail library interprets that data as a file path or URL, enabling local file disclosure and SSRF from the n8n host.
- Impact is exposure of configuration files, environment variables, or stored credentials that can widen access beyond the workflow itself.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
- 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
Workflow-hosted secrets create a governance gap, not just an input-validation issue. The article shows that the vulnerable path becomes dangerous only when a workflow holds SMTP credentials and accepts untrusted body fields through a public trigger. That combination means automation platforms need identity and secret governance, not just patch management. Practitioners should treat workflow engines as sensitive control points, not low-risk glue code.
Public webhooks are the real exposure amplifier here. The flaw is technically in the Send Email node, but the practical risk appears when unauthenticated workflow entry points are allowed to feed privileged actions. That is a classic boundary failure in workflow security: external reachability meets internal trust. Teams should assume any public trigger can become a secret-disclosure path if it is connected to a node that touches files, URLs, or credentials.
File-read in an automation platform has a larger blast radius than the same defect in a single app. n8n instances often sit close to multiple systems and retain the credentials needed to operate them. That makes SSRF and local file disclosure especially dangerous because the platform can become a pivot into cloud, email, or internal service access. The governance lesson is to map where workflows inherit privilege and to reduce that inheritance aggressively.
Type confusion should be read as an authorization failure in disguise. If a workflow input can cross from user-controlled text into a library that interprets it as a path or request target, then the platform has failed to preserve intended data meaning across boundaries. That is a control-design problem as much as a coding bug. Practitioners should require explicit data typing and strict content binding for every field that can affect execution.
Automation platforms need a named control concept: workflow trust boundary collapse. This is the point where public input, privileged connectors, and stored secrets converge inside one runtime. Once that boundary collapses, the platform stops being a helper application and starts behaving like a shared trust broker. Security teams should govern it with the same discipline they apply to privileged integration services and secret-bearing workloads.
What this signals
Workflow trust boundary collapse: n8n-style automation turns risky when public input can cross directly into nodes that can touch files, URLs, or stored credentials. The governance failure is not the existence of automation itself, but the absence of a controlled boundary between external triggers and privileged execution. Teams should map every workflow that can reach secrets-bearing nodes and redesign those paths so untrusted data cannot influence transport behaviour.
Self-hosted automation platforms should be treated as integration-tier assets with privileged access assumptions, not as low-value utility tools. Once they hold SMTP credentials or other stored secrets, a file-read flaw can become a platform-level incident rather than a single-node defect. That should change patch priority, segmentation choices, and the way security teams inventory these systems across business units.
For practitioners
- Inventory externally reachable workflow engines Build a complete list of internet-facing n8n instances, including subsidiary, cloud-hosted, and lab deployments that may have escaped central tooling.
- Remove untrusted input from privileged email paths Review workflows for Send Email nodes that accept webhook data directly in text or html fields and redesign those flows so untrusted values are handled separately.
- Restrict public webhook access Place reverse-proxy or network controls in front of workflows that do not need open internet reachability, especially where credentials are already stored in the instance.
- Rotate secrets on exposed instances Assume SMTP credentials and any other stored secrets on externally reachable instances may be exposed and replace them after patching and workflow review.
- Tighten workflow edit permissions Limit creation and editing rights to trusted operators so unauthorised users cannot introduce new public triggers or unsafe field mappings into privileged flows.
Key takeaways
- The core risk in CVE-2026-72766 is not simply a parsing flaw, but a workflow design pattern that lets untrusted input reach privileged mail handling.
- The article shows that the vulnerability becomes exploitable only when a public webhook, SMTP credentials, and direct body-field mapping are all present.
- Teams can reduce the blast radius by removing public reachability, separating untrusted input from privileged nodes, and rotating any secrets stored on exposed instances.
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 CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Workflow-hosted credentials and files are exposed through the vulnerable node path. |
| NHI-05 — Overprivileged NHI | The instance holds more privilege than the workflow trigger should be able to reach. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Externally reachable self-hosted deployments and open webhooks create the exploitable condition. | |
| Recommendation — Scan workflow runtimes for secret leakage paths and revoke any credentials reachable through exposed nodes. Reduce NHI privilege scopes so public workflow triggers cannot access file- or secret-bearing actions. Harden deployment exposure so workflow services are not publicly reachable unless the business case requires it. | ||
| MITRE ATT&CK | TA0006;TA0007 — Credential Access; Discovery | The attack path uses file disclosure to expose secrets and internal host information. |
| Recommendation — Map exposed workflow paths to credential access and discovery tactics in detection and hunt content. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The flaw becomes dangerous when public triggers can reach privileged workflow actions. |
| Recommendation — Review workflow entitlements so external input cannot invoke privileged actions without authorization. | ||
Key terms
- Workflow trust boundary: A workflow trust boundary is the point where one step in a business or technical process stops being fully trusted and must be checked before the next step continues. It defines where identity, data, or action permissions change, and where controls such as approval, validation, logging, or isolation should be applied.
- Type Confusion: A software flaw where a program treats data as the wrong type. In protocol parsers, that mistake can cause crashes, memory corruption, or unsafe method calls when attacker-controlled input is decoded incorrectly and then passed into functions that expect a different data structure.
- Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
- Workflow-Hosted Secrets: Workflow-hosted secrets are credentials, tokens, or configuration values stored inside an automation platform so it can connect to other systems. They are valuable because one compromised workflow can expose the secrets needed to pivot into email, cloud, or business applications beyond the original flaw.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners who need to connect secret governance, access control, and lifecycle discipline to broader security programmes.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org