Three Nodemailer address-parsing flaws let attackers redirect mail to domains their own validation rejected

What happened

Security researchers identified three distinct parsing errors in Nodemailer's addressparser component, all stemming from the same root cause: addressparser stops reading a structural character (a closing angle bracket '>', a group-terminating semicolon ';', or a comment-closing parenthesis ')') at the first occurrence of that character, even when it appears inside a quoted string, a comment, or a nested comment. A standards-compliant RFC 5322 parser correctly tracks whether such characters are inside quoted or nested content and ignores them there. GHSA-85x2-q946-cp5h affects angle-address parsing: a '>' inside a quoted local part ends the address early, causing the domain to be misread. GHSA-m943-m63m-w62w affects address groups: a ';' inside a quoted display name or comment ends the group early, turning display text into a live recipient address. GHSA-8c8m-p3m8-cjg8 affects nested comments: a nested closing parenthesis ends the outer comment early, releasing text that should have been a comment as a recipient address.

Technical cause

In all three cases, addressparser lacks proper state tracking for quoted strings, comments, and nested comments while scanning for structural delimiters. It treats the first occurrence of a delimiter character as significant regardless of context, whereas RFC 5322 requires that characters inside quoted strings or comments (including nested ones) be treated as literal text, not syntax. Because the resulting misparsed values are still syntactically valid RFC 5322 addresses, parsers that correctly implement the standard (the advisories cite Python's email._header_value_parser.get_address_list as an example) accept them without reporting any defect, while Nodemailer derives a different address or recipient from the same input. The fixes add explicit tracking of quoted-string, comment, and domain-literal state so that structural characters are only honored outside that state, and comment depth is tracked so only the outermost closing parenthesis ends a comment.

Why it matters

Applications commonly validate user-supplied recipient or sender addresses with a separate, standards-compliant parser or a domain allow-list before handing the value to Nodemailer for sending. Because the crafted addresses in these advisories are valid under RFC 5322, such validation approves them. Nodemailer then parses the same string differently and sends the message, or builds the outgoing envelope (RCPT TO), using a domain or mailbox the application's header did not intend and the validation step did not catch. This lets an attacker cause an application to deliver mail — potentially containing sensitive content such as invitations, notifications, or password reset information — to a domain or address of their choosing, bypassing the application's recipient allow-list. In the inbound direction, when the standalone addressparser module is used by consumers like mailparser to read incoming mail, it can report a different sender or recipient than a conformant parser reads from the same header, creating a mismatch useful for sender spoofing or display-layer deception.

Who is affected

Any application that passes user-influenced email addresses (recipient lists, sender addresses, or address fields built from user input) to Nodemailer for outbound mail is affected, particularly those that rely on domain allow-lists or separate RFC 5322 validation as a security boundary. Consumers of the standalone addressparser module outside of Nodemailer itself — the advisories specifically name mailparser — are also affected when parsing inbound mail headers, since the same parsing logic is shared.

Discovery and timeline

All three issues were found during an internal review of addressparser conducted on 2026-10-18 and verified against Nodemailer versions 3.0.0, 6.9.16, and 10.1.3. The advisories note that one of the three issues (the nested-comment case) is structurally related to an earlier, separately fixed issue involving an escaped parenthesis that was addressed in version 10.1.2, reached here through comment nesting instead of a quoted-pair. The three advisories were published on 2026-10-23.

Affected versions

Nodemailer versions 3.0.0 through 10.1.3 are affected by all three issues. Version 10.1.4 contains fixes for all three. The fact package does not specify which exact point releases between 3.0.0 and 10.1.3 were individually tested beyond the three versions explicitly named as verified (3.0.0, 6.9.16, and 10.1.3).

Fixes and mitigation

Nodemailer 10.1.4 fixes all three issues by adding proper state tracking: quoted strings, comments, and domain literals are now tracked inside an angle-addr so a closing '>' is only honored outside them; quoted strings and comments are tracked inside address groups so a ';' is only honored outside them; and comment nesting depth is tracked so only the outermost closing parenthesis ends a comment. Applications and libraries (including mailparser, which shares the underlying parser logic) that depend on Nodemailer's address parsing should update to 10.1.4 or later.

Recommended action

Update Nodemailer to version 10.1.4 or later as soon as practical. If your application enforces recipient domain allow-lists or other address-based access controls using a separate validation library, re-verify that validation logic agrees with Nodemailer's actual parsing behavior after upgrading, since the two having different interpretations of the same address is the root cause of this class of issue. If you use mailparser or another consumer of the standalone addressparser module to process inbound mail, confirm it also receives the corresponding fix, as the same underlying parsing logic is affected.