GHSA-2x35-3fw4-9jr4: n8n: Send Email Node Arbitrary File Read and SSRF via Nodemailer Content-Object Type Confusion

Nodemailer accepts a content object in place of a plain string. The object can point to a file path or a URL. The Send Email node passed whatever a workflow expression produced into the text or HTML body without forcing it to be a string. If an attacker controls that value, Nodemailer treats it as a content object and reads the file or fetches the URL (type confusion, with file read and SSRF outcomes). The file contents end up in the outgoing email.

Exploitation needs several things together. The workflow must be active and have an unauthenticated webhook. The Send Email node must have working SMTP credentials. Untrusted input must be mapped directly into the text or HTML body field. The advisory says this is not a default n8n configuration.

When those conditions hold, a remote caller with no account can have local files from the n8n host sent to a mailbox, and can make the server request internal URLs. Config files, environment files and credentials on the host are the usual targets. The CVSS 4.0 vector rates confidentiality impact high and the other impacts none.

Affected: n8n below 1.123.67 on the 1.x line, 2.0.0-rc.0 up to but not including 2.31.5, and 2.32.0. Only instances with an active unauthenticated-webhook workflow that feeds untrusted data into the Send Email node's text or HTML body are practically exposed.

Check the version:

npm ls n8n

Then review active workflows for Send Email nodes whose body fields use webhook data expressions.

Upgrade to n8n 1.123.67, 2.31.5 or 2.32.1, or later. The fix touches the EmailSend node code (v1, v2 send and sendAndWait operations and their utils).

Temporary mitigations from the advisory, none of which fully remove the risk:

• Audit active workflows for Send Email nodes that map webhook or external data straight into the text or HTML body, then remove or restrict them.
• Restrict public webhook access at the network or reverse-proxy level.
• Limit workflow creation and editing to fully trusted users.

The sources give no log signature. Find webhook-triggered workflows with a Send Email node whose text or HTML field uses an expression from the webhook payload. In the execution history, look for requests where that payload field is a JSON object, with keys like path or href, rather than a string. Check the outbox of the SMTP account for messages that contain file contents such as env or config data. Check egress logs for odd requests from the n8n host to internal addresses.

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.