n8n file-read CVE-2026-72766 exposes workflow-hosted secrets

At a glance

What this is: CYCOGNITO’s analysis shows that a type confusion flaw in n8n’s Send Email node can expose host files and internal requests when specific webhook and email configurations are present.

Why it matters: For IAM and security teams, the risk is that automation platforms often hold high-value secrets and delegated access, so a file-read flaw can become a secrets exposure event rather than a single-application bug.

By the numbers:

• The affected n8n versions include releases before 1.123.67, 2.31.5, and 2.32.1.
• When public AWS credentials are exposed, attackers attempt access within an average of 17 minutes.

👉 Read CYCOGNITO's analysis of CVE-2026-72766 and n8n file-read exposure

Context

n8n is an automation layer that often sits between systems with access to emails, APIs, and stored credentials. When a workflow engine carries secrets and accepts untrusted input, a single input-validation flaw can widen into file disclosure, server-side request forgery, and downstream credential exposure rather than remaining a narrow application bug. The primary keyword here is n8n file-read vulnerability, and that matters because workflow tools are increasingly treated as infrastructure.

The governance gap is that many self-hosted automation instances are deployed quickly, connected broadly, and then left outside normal application inventory and patch discipline. In identity terms, these platforms frequently function as concentrated holders of non-human identity material, including SMTP credentials, API keys, and environment variables. That makes their exposure profile closer to a privileged integration layer than to an ordinary business application.

This deployment pattern is common for departmental workflows and proof-of-concept automation. It becomes risky when webhook reachability, direct data mapping, and stored credentials coexist without strong lifecycle control and review.

Key questions

Q: What fails when an automation workflow can pass untrusted input into a mail node?

A: The failure is trust propagation. If a workflow lets attacker-controlled data reach a mail library without strict type checks, the library can misread that input as a path or URL and disclose local files or trigger internal requests. That is why workflow validation has to happen before the runtime touches secrets or network-bound functions.

Q: Why do self-hosted workflow platforms create higher secrets risk than ordinary apps?

A: They often sit between multiple systems and store the credentials needed to connect them. That means a file read or configuration leak can expose SMTP credentials, API keys, and environment variables that unlock other services. The risk is less about the app itself and more about the concentration of non-human identity material it holds.

Q: How can security teams know whether n8n-style exposure is actually dangerous?

A: Check three signals together: reachable unauthenticated webhooks, nodes that accept direct external input, and any workflow host that stores reusable credentials. If all three are present, the issue is not theoretical. The platform has enough trust, reach, and secret value for a small flaw to become a broad exposure path.

Q: Who is accountable when a workflow leaks secrets through deployment abuse?

A: Accountability usually spans repository owners, platform engineering, and the teams that defined the workflow and its permission model. Security governance frameworks expect explicit control ownership, because automation failures are still governance failures. For NHI programmes, the accountable party is whoever owns the machine identity, its scopes, and the approval gates around it.

Technical breakdown

How the Send Email node turns type confusion into file disclosure

The flaw sits in input handling. The Send Email node does not guarantee that message fields remain strings, so a workflow expression can pass a non-string value into Nodemailer. Instead of treating that value as message content, the downstream library may interpret it as a file path or URL. That creates a path from attacker-controlled input to local file reads and outbound requests. Because the issue lives in a standard node, not an optional extension, the vulnerable behaviour can exist in ordinary deployments without custom code.

Practical implication: validate every workflow path that maps untrusted data into email body fields and remove direct expression passthrough where possible.

Why webhook reachability and SMTP configuration matter together

Exploitation depends on deployment state, not authentication to n8n itself. An attacker needs an unauthenticated webhook that is reachable, valid SMTP credentials configured on the Send Email node, and untrusted input mapped into the body field. Those conditions combine to let a remote user influence what the mail library receives. The result is not just application abuse. It is a platform-level trust failure because the workflow engine is acting with credentials and network reach that the original input should never inherit.

Practical implication: treat unauthenticated webhooks and stored SMTP credentials as a single risk chain, not separate configuration items.

Why file read in workflow platforms becomes a secrets problem

A file read on an automation host is especially valuable because these systems often store configuration files, environment variables, and embedded integration credentials. In practice, that means a local read can surface the secrets needed to move from one workflow to other connected systems. The SSRF element compounds the issue by making internal network requests appear to originate from within the automation segment. In identity terms, the platform can become a pivot point for abusing non-human identities rather than just a place where data leaks.

Practical implication: assume a read from the workflow host can expose non-human identity material and segment the platform accordingly.

Threat narrative

Attacker objective: The attacker aims to harvest files and credentials from the automation host, then use that access to pivot into connected systems and expand control.

1. Entry occurs through an exposed unauthenticated webhook on a self-hosted n8n instance.
2. Credential access and abuse follow when attacker-controlled input reaches the Send Email node and is interpreted by Nodemailer as a path or URL.
3. Impact occurs through local file disclosure and server-side request forgery from inside the n8n network segment, which can expose secrets used by connected systems.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• Gravity SMTP CVE-2026-4020 API Keys Exposure — CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

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

NHI Mgmt Group analysis

Workflow automation platforms are becoming concentrated non-human identity assets. n8n instances often store SMTP credentials, environment variables, and integration tokens, which means a flaw in one node can expose an identity-rich control plane rather than a single app. That changes how defenders should classify these systems under IAM and PAM. Treating them as ordinary internal tooling understates the blast radius; practitioners should inventory and govern them as privileged integration services.

Deployment conditions now matter as much as the vulnerability itself. The exploit chain depends on unauthenticated webhooks, direct input mapping, and stored credentials, which means vulnerability management alone will miss the real risk boundary. This is a governance gap, not just a patch gap, because control effectiveness depends on how the workflow is used. Teams should measure exposure by reachable webhook paths and secret-bearing nodes, not just by version numbers.

Standing secret exposure is the named failure mode this issue exposes. The problem is not merely that a file can be read, but that the file system on an automation host may contain reusable credentials that outlive the workflow that needs them. In OWASP NHI terms, this resembles unmanaged secret persistence inside a runtime that also accepts external input. Practitioners should force shorter secret lifecycles and reduce stored credential scope before assuming patching alone is enough.

Patch timeliness is necessary but insufficient for workflow risk. The fixed n8n versions close the code path, but they do not remove exposed webhooks, over-broad workflow permissions, or weak secret placement. NIST CSF and CIS Controls both point toward asset visibility, access control, and secure configuration as the operating model, while NIST SP 800-53 IA and AC controls map directly to the trust decisions here. The practical conclusion is to govern the platform as a credential-bearing service, not a lightweight automation app.

From our research:

• When public AWS credentials are exposed, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Also from our research: DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
• For the broader pattern: Explore The 52 NHI breaches Report for recurring credential exposure failures and Ultimate Guide to NHIs , Key Challenges and Risks for lifecycle controls that reduce persistence.

What this signals

Standing secret exposure: automation platforms now behave like identity-rich infrastructure, which means webhook reachability and stored credentials should be measured as one control problem. For teams that run workflow engines alongside application delivery, the next step is to align configuration review with NIST SP 800-53 Rev 5 Security and Privacy Controls and secret lifecycle discipline, not just patch reporting.

n8n-style deployments are a reminder that workflow systems can become shadow integration hubs when they are not inventoried and owned centrally. That makes external exposure monitoring and credential rotation part of the same operating model, especially where service accounts and SMTP secrets support business automation.

For practitioners

• Inventory all externally reachable automation instances Identify every self-hosted n8n deployment, including subsidiary, cloud-hosted, and proof-of-concept instances. Confirm which ones expose unauthenticated webhooks and which ones hold SMTP credentials or other secrets on the host. The highest-risk assets are often the ones outside central application inventory.
• Remove direct untrusted input from email body fields Review every workflow that feeds webhook data into the Send Email node and break the direct expression path where user-controlled values can reach message fields. Enforce explicit type validation and constrain acceptable input formats before the mail library sees them.
• Restrict webhook exposure at the network edge Place reverse proxy or network controls in front of public webhook endpoints so unauthenticated requests cannot reach sensitive workflow paths by default. Where public exposure is unavoidable, isolate the workflow and strip stored credentials from any node that can be triggered externally.
• Rotate secrets on exposed workflow hosts Rotate SMTP credentials and any adjacent integration tokens on instances that were externally reachable before remediation. Treat the file-read possibility as a credential exposure event and assume host-level configuration files may already have been harvested.
• Reclassify workflow engines as privileged services Move automation platforms into the same governance tier used for privileged integration layers. Apply tighter edit permissions, routine configuration review, and access logging so workflow changes cannot silently expand the blast radius of stored credentials.

Key takeaways

• A type confusion flaw in a workflow email node can turn ordinary automation into a file-read and SSRF exposure path.
• The real risk comes from exposed webhooks plus stored credentials, which can convert a bug into a secrets harvesting event.
• Teams should govern automation platforms as privileged integration services and reduce secret persistence before relying on patching alone.

Key terms

• Workflow platform: A workflow platform automates tasks across systems by moving data, credentials, and decisions through connected nodes. In security terms, it becomes part of the control plane when it can access email, APIs, databases, or internal services, so its trust boundary must be governed like other privileged infrastructure.
• 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.
• Nonhuman Identity: A nonhuman identity is any machine or software identity used to access systems, including service accounts, API keys, tokens, certificates, workloads, bots, and AI agents. In practice, it needs the same governance discipline as human identity, but with stronger emphasis on runtime context, lifecycle automation, and revocation.

What's in the full analysis

CYCOGNITO's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact vulnerable version lines and fix branches for self-hosted n8n deployments
• CyCognito's exposure distribution data across sectors and deployment patterns
• The recommended remediation sequence for webhook control, workflow auditing, and secret rotation
• CyCognito's Emerging Threat Advisory context for CVE-2026-72766

👉 CYCOGNITO's full post covers the exposed asset patterns, remediation guidance, and affected versions in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for teams that need to control credential-rich systems. It helps practitioners connect identity governance to the operational realities of automation platforms and other non-human identity estates.