CVE-2026-72766 is a type confusion flaw in the n8n Send Email node. Non-string input in the body field can be read by the mail library as a file path or URL, exposing local files or enabling server-side request forgery. The record scores it 7.5, High. Upgrade to 1.123.67, 2.31.5 or 2.32.1.
What's affected
The advisory lists affected versions as anything before 1.123.67 on the 1.x line, before 2.31.5 on the 2.31 line, and before 2.32.1 on the 2.32 line. The patched releases are 1.123.67, 2.31.5 and 2.32.1.
The advisory is specific about what makes an instance exposed. It needs an active workflow with an unauthenticated webhook, valid SMTP credentials on the Send Email node, and untrusted input mapped directly into the text or HTML body field. The advisory says this is not a default configuration. If your workflows never feed outside input into the email body, you have a smaller exposure, but you should still upgrade.
The weakness class is CWE-843, access of a resource using an incompatible type. The node expected a string and accepted something else.
How to check if you're exposed
Find the version of every n8n instance you run, including containers and any copy bundled in another product.
n8n --version
docker exec <container-name> n8n --version
npm ls n8n
If the version is below the patched release for your line, you are in the affected range. Remember that n8n often runs as a base image tag in Docker or Kubernetes, so check image tags in your manifests as well as running hosts. A dependency scan of the repository that holds your deployment files will surface pinned n8n packages. The free in-browser scan at gold.safeguard.sh/scan accepts a manifest and lists known CVEs for what it finds.
Then review your workflows for the pattern the advisory describes. Look for any workflow that starts with a webhook that needs no authentication, passes through a Send Email node, and maps webhook data straight into the message text or HTML field. Export your workflows and search them for Send Email nodes, then trace where their body fields get their values.
What to do now
- Upgrade n8n to 1.123.67, 2.31.5 or 2.32.1 or later.
- Find workflows that connect an unauthenticated webhook to a Send Email node and fix the mapping so outside input never lands directly in the body field.
- Put authentication on webhooks that do not need to be public.
- Check whether the n8n host holds files you would not want exposed, such as environment files or key material, and rotate anything you think could have been read.
- Limit outbound access from the n8n host to internal addresses, since the flaw can also cause server-side requests.
- Confirm the new version on each instance after the upgrade.
Why it matters
The mail library behind the node accepts rich message objects. A field that is meant to hold text can instead hold a reference, such as a path or URL, that the library then loads and attaches. When the node does not insist that the field is a string, a value shaped like that reference gets treated as an instruction to read something. This is a common pattern in typed languages that lose their types at the edge of a workflow expression.
The sources differ on scoring. The record gives 7.5 under CVSS 3.1 with confidentiality as the only impact. VulnCheck gives 8.2 under CVSS 4.0, and the GitHub advisory labels it High. The ratings agree on direction. The advisory text mentions disclosure of local files, while the record also names server-side request forgery. Plan for both. No source says this has been exploited, and it is not in the CISA KEV catalog.
Quick check
Is every n8n instance with a Send Email node at risk?
No. The advisory requires an active workflow with an unauthenticated webhook, SMTP credentials on the node, and untrusted input mapped straight into the body field. It is not a default setup. Upgrading is still the right step.
What kind of bug is this?
Type confusion. The node did not enforce that its message fields were strings, so the mail library could treat a crafted value as a file path or URL.
Sources
Last reviewed: 18 October 2026.
