Nodemailer before 10.0.9 Malformed Envelope Recipient via RFC 5322 Comment

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

Nodemailer is a Node.js email-sending library. In versions >= 9.1.0 and < 10.0.9, the address parser (src/addressparser) mishandles addresses whose local-part is a quoted string and that are followed by RFC 5322 comments, allowing trailing comment-separated domain atoms to be retained in the normalized address. For example, the input "user"@example.com(x)evil.com is parsed to the address value '[email protected] evil.com', which contains additional attacker-controlled domain text separated by a literal space. This parsed value is used without further strict recipient validation when the message envelope is built (envelope.to in src/mime-node), so a malformed/ambiguous recipient address can be accepted and placed in the SMTP envelope. Whether this results in delivery to an unintended recipient on real SMTP servers has not been confirmed. The issue is a variant of the RFC 5322 comment parsing problem addressed in GHSA-cc9r-2j5m-2m83, affecting the separate quoted-local-part code path. Version 10.0.9 contains a fix.

Source published

26 Sep 2026 13:23:55 UTC

Source modified

28 Sep 2026 17:43:19 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · 6.9 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

CVSS 3.1 · 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Nodemailer is a Node.js email-sending library. In versions >= 9.1.0 and < 10.0.9, the address parser (src/addressparser) mishandles addresses whose local-part is a quoted string and that are followed by RFC 5322 comments, allowing trailing comment-separated domain atoms to be retained in the normalized address. For example, the input "user"@example.com(x)evil.com is parsed to the address value '[email protected] evil.com', which contains additional attacker-controlled domain text separated by a literal space. This parsed value is used without further strict recipient validation when the message envelope is built (envelope.to in src/mime-node), so a malformed/ambiguous recipient address can be accepted and placed in the SMTP envelope. Whether this results in delivery to an unintended recipient on real SMTP servers has not been confirmed. The issue is a variant of the RFC 5322 comment parsing problem addressed in GHSA-cc9r-2j5m-2m83, affecting the separate quoted-local-part code path. Version 10.0.9 contains a fix.

Source published

Sep 26, 2026, 1:23:55 PM (timezone not stated)

Source modified

Sep 28, 2026, 5:43:19 PM (timezone not stated)

Observed here

11 Nov 2026 05:27:38 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 4.0 · 6.9 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Nodemailer is a Node.js email-sending library. In versions >= 9.1.0 and < 10.0.9, the address parser (src/addressparser) mishandles addresses whose local-part is a quoted string and that are followed by RFC 5322 comments, allowing trailing comment-separated domain atoms to be retained in the normalized address. For example, the input "user"@example.com(x)evil.com is parsed to the address value '[email protected] evil.com', which contains additional attacker-controlled domain text separated by a literal space. This parsed value is used without further strict recipient validation when the message envelope is built (envelope.to in src/mime-node), so a malformed/ambiguous recipient address can be accepted and placed in the SMTP envelope. Whether this results in delivery to an unintended recipient on real SMTP servers has not been confirmed. The issue is a variant of the RFC 5322 comment parsing problem addressed in GHSA-cc9r-2j5m-2m83, affecting the separate quoted-local-part code path. Version 10.0.9 contains a fix.

Source published

26 Sep 2026 14:16:54 UTC

Source modified

30 Sep 2026 16:32:17 UTC

Observed here

25 Oct 2026 04:17:26 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · [email protected] · Secondary · 6.9 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

CVSS 3.1 · [email protected] · Secondary · 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

## Summary Nodemailer's address parser can produce an unexpected recipient address when an RFC 5322 comment follows the domain of an address whose local-part is a quoted string. For example: ```text "user"@example.com(x)evil.com ``` is parsed as: ```text { address: "[email protected] evil.com", name: "" } ``` The resulting address therefore contains additional attacker-controlled domain text separated by a literal space. The parsed `.address` value is subsequently propagated into the SMTP envelope: ```text src/addressparser/index.ts ↓ recipient.address ↓ src/mime-node/index.ts ↓ envelope.to ``` The envelope construction uses the parsed address without another strict address validation step. This appears to be a variant of the RFC 5322 comment parsing issue addressed by GHSA-cc9r-2j5m-2m83, but it follows a different parser path when the local-part is quoted. ## Reproduction Input: ```text "user"@example.com(x)evil.com ``` Observed parser output: ```text address: "[email protected] evil.com" name: "" ``` A second example: ```text "a"@b.com(c)d.com(e)f.com ``` produces: ```text address: "[email protected] d.com f.com" name: "" ``` For comparison, the corresponding unquoted form: ```text [email protected](x)evil.com ``` takes a different code path and is handled by the existing protection differently. ## Technical Details The issue is caused by different parsing behavior for quoted and unquoted local-parts. The quoted-local-part variant allows the comment-separated trailing domain atoms to remain in the resulting `.address` value. That value is then used when constructing the message envelope: ```text envelope.to = recipients.map(to => to.address as string) ``` No additional strict recipient validation is performed at this boundary. ## Security Impact The confirmed impact is that attacker-controlled comment content can result in a malformed/ambiguous recipient address being accepted by the parser and propagated into `envelope.to`. The reporter did **not confirm successful delivery to an unintended recipient through a real SMTP server using this exact quoted-local-part variant**. The remaining question is how real SMTP servers and other Nodemailer transports handle an envelope recipient containing a value such as: ```text [email protected] evil.com ``` An end-to-end SMTP test is required to determine whether this parser behavior results in an exploitable delivery or recipient-validation bypass. ## Relationship to GHSA-cc9r-2j5m-2m83 This report is intended as a potential variant/follow-up to GHSA-cc9r-2j5m-2m83. The existing advisory addresses RFC 5322 comment handling in email domains. This report identifies a separate parser path involving quoted local-parts that can preserve additional domain-like content in the normalized address. Please evaluate whether this behavior is already covered by the existing fix or represents a remaining parser variant. ## Suggested Fix The parser should consistently reject or correctly terminate addresses containing trailing domain atoms after RFC 5322 comments, regardless of whether the local-part is quoted. In particular: ```text "user"@example.com(x)evil.com ``` should not result in: ```text [email protected] evil.com ``` The envelope-generation layer should also avoid assuming that a parser-produced address is safe for SMTP delivery without appropriate validation. ## Verification Status Confirmed: * Parser accepts the quoted-local-part variant. * Parser produces an address containing additional attacker-controlled text. * The resulting address is propagated into `envelope.to`. Not confirmed by reporter: * Successful delivery through a real SMTP server. * Delivery to an unintended recipient. * Exploitability against a specific downstream SMTP implementation.

Source published

29 Sep 2026 23:44:04 UTC

Source modified

30 Sep 2026 00:00:03 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Publisher rating · MODERATE