GHSA-g73g-hqqh-jr95

Nodemailer: RFC 5322 comment inside an angle-bracket address is never stripped

Published

2026-10-27

Modified

2026-10-27

Sources

github-advisory

Summary

## Summary Nodemailer's address parser has three published, patched fixes for RFC 5322 comment `( ... )` handling inside an addr-spec: GHSA-cc9r-2j5m-2m83 (comment glued two domain atoms into one), GHSA-g57g-f23g-4646 (the same glue for a quoted local part), and the related ReDoS fixes GHSA-prgh-xp8r-p3m5 / GHSA-v53p-9fqp-m79j. All three fixes live in `_handleAddress()`'s `joins` / `_recoverAddrSpec()` logic in `src/addressparser/index.ts`, and that logic is exercised whenever the local text-accumulation path in the tokenizer runs. That logic is **never reached at all** for the single most common way a recipient is written: a display name followed by an angle-bracket address, `Name `. When the input inside the angle brackets itself contains an RFC 5322 comment, e.g. ``` Legit User ``` the comment is not recognized as an operator, is not stripped, and the parenthesis characters survive **verbatim** inside the parsed address. That value is used as-is for `envelope.to` and is written raw onto the wire in the `RCPT TO` SMTP command. I confirmed this end to end: * against nodemailer's own `jsonTransport`/`streamTransport` (`envelope.to` and the emitted `To:` header both carry the malformed value), and * against a real SMTP server (`aiosmtpd`), where the malformed value is fatal to the transaction (`501 Syntax: RCPT TO: [SP ]`, all recipients rejected). This reproduces unmodified on every version I tested from `6.9.16` through the current `10.0.12` HEAD, i.e. it predates and survives all three of the address-parser advisories above unchanged, because it is a different root cause in a code path those fixes never touch. ## Root cause ### 1. The tokenizer has a single-slot operator stack `src/addressparser/index.ts`, `Tokenizer.checkChar()`: ```ts } else if (!this.operatorExpecting && !this.inDomainLiteral && chr in this.operators) { this.node = { type: 'operator', value: chr }; this.list.push(this.node); this.node = null; this.operatorExpecting = this.operators[chr]; this.escaped = false; return; } ``` (currently around line 670) `operatorExpecting` is a single string, not a stack. Once ` '`. The branch above that recognizes a *new* operator character (such as `(`) is gated on `!this.operatorExpecting`, which is now false. So while inside ` `, a `(` is never tokenized as an operator at all — it is just an ordinary character appended to the running text token, together with everything up to the next `>`. The RFC 5322 comment is not recognized, not entered, and not stripped: it rides straight through as literal text. ### 2. The `_handleAddress` state machine loses the `address` state on any operator boundary `src/addressparser/index.ts`, inside `_handleAddress()` (currently around line 365-388): ```ts switch (token.value) { case ' `, none of that applies in the first place (point 1), so there is no text-bucket safety net to fall back on — the whole point 1/point 2 interaction is what makes the angle-bracket case categorically different from, and unprotected by, the three existing fixes. ### 3. The one existing safety net requires whitespace, and this value has none `_recoverAd

Affected packages

Remediation: Upgrade to 10.0.13 or later.

References

• https://github.com/advisories/GHSA-g73g-hqqh-jr95