GHSA-2x35-3fw4-9jr4: n8n: type confusion in Send Email leaks host files

## Impact The n8n Send Email node did not enforce that its message fields were strings, so a crafted untrusted non-string value from a workflow expression could be treated by the underlying mail library as a file path or URL. This could allow disclosure of local files on the n8n host. Exploitation requires a pre-existing active workflow with an unauthenticated webhook, valid SMTP credentials configured on the Send Email node, and untrusted input mapped directly into the text or HTML body field. This is not a default n8n configuration. ## Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability. ## Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Audit active workflows for Send Email nodes that map untrusted webhook or external data directly into the text or HTML body fields, and remove or restrict those workflows. - Restrict public webhook access at the network or reverse-proxy level to prevent unauthenticated callers from reaching sensitive workflows. - Restrict workflow creation and editing permissions to fully trusted users only. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

An organization runs an n8n workflow that receives external form or alert data via an unauthenticated webhook and forwards a summary email using the Send Email node, with the email body populated from a workflow expression referencing the incoming payload. An attacker submits a crafted JSON payload where the field mapped to the email body is not a plain string but an object or array shape that the mail library's parameter handling misinterprets as a file path or URL (e.g., referencing `/etc/passwd`, a cloud metadata URL, or a local secrets file). The Send Email node passes this value through unchanged, the mail library resolves it as a path/URL instead of literal text, and the contents of that local file are read and delivered via email to whatever recipient the workflow is configured to send to — potentially the attacker if the workflow reflects a reply-to or CC field, or an internal address the attacker can later access.