GitHub Advisoryadvisory · npm

GHSA-g73g-hqqh-jr95 Nodemailer: RFC 5322 comment inside an angle-bracket address is never stripped

MEDIUM Published 2026-10-27 Modified 2026-10-27 Official page ↗
Ecosystem
npm
Packages
nodemailer
Severity
Moderate
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Weaknesses
CWE-20, CWE-436
Reviewed
2026-10-27

Affected packages

• npm nodemailer: >= 3.0.0, < 10.0.13 → fixed in 10.0.13

Description

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 `_recoverAddrSpec()` (currently around line 283) is the function all three prior fixes rely on to peel a clean addr-spec back out of a polluted value. Its very first line is: ```ts function _recoverAddrSpec(data: { address: string; text: string }): void { if (!HAS_WHITESPACE.test(data.address)) { return; } ... ``` `[email protected](x)evil.com` contains no whitespace at all — the comment content `x` had none, and nothing in the angle-bracket path inserts any — so `_recoverAddrSpec` bails out immediately and never even looks at the value. There is no cleanup path for this shape. Proof of Concept Environment: Node.js, current `master` (commit `30e4cfd5902fd5da4d1bc76dc8e4bc92d288adef`, package.json version `10.0.12`), no special transport configuration required. Parser-level confirmation ```js const addressparser = require('nodemailer/lib/addressparser'); console.log(addressparser('Legit User ')); // [ { address: '[email protected](x)evil.com', name: 'Legit User' } ] ``` Compare with the already-fixed, unbracketed form of the exact same bytes: ```js console.log(addressparser('[email protected](x)evil.com')); // [ { address: '[email protected]', name: 'evil.com' } ] { const t = nodemailer.createTransport({ jsonTransport: true }); const info = await t.sendMail({ from: '[email protected]', to: 'Legit User ', subject: 'hi', text: 'x' }); console.log('envelope.to:', info.envelope.to); })(); ``` Observed output: ``` envelope.to: [ '[email protected](x)evil.com' ] ``` The raw `streamTransport` message shows the same value in the emitted header: ``` From: [email protected] To: Legit User Subject: hi ``` Wire-level confirmation against a real SMTP server ```js const net = require('net'); const nodemailer = require('nodemailer'); const server = net.createServer(sock => { let buf = ''; sock.write('220 sink ESMTP\r\n'); sock.on('data', d => { buf += d; let i; while ((i = buf.indexOf('\r\n')) >= 0) { const line = buf.slice(0, i); buf = buf.slice(i + 2); const u = line.toUpperCase(); if (u.startsWith('EHLO')) sock.write('250-sink\r\n250 8BITMIME\r\n'); else if (u.startsWith('MAIL')) sock.write('250 ok\r\n'); else if (u.startsWith('RCPT')) { console.log('wire RCPT TO :', line); sock.write('250 ok\r\n'); } else if (u.startsWith('DATA')) sock.write('354 go\r\n'); else if (line === '.') sock.write('250 ok\r\n'); else if (u.startsWith('QUIT')) { sock.write('221 bye\r\n'); sock.end(); } else sock.write('250 ok\r\n'); } }); }); server.listen(0, '127.0.0.1', async () => { const t = nodemailer.createTransport({ host: '127.0.0.1', port: server.address().port, secure: false }); const info = await t.sendMail({ from: '[email protected]', to: 'Legit User ', subject: 'hi', text: 'x' }); console.log('envelope.to:', info.envelope.to); t.close(); server.close(); }); ``` Observed: ``` wire RCPT TO : RCPT TO: envelope.to: [ '[email protected](x)evil.com' ] ``` The same recipient string sent at a real, conformant SMTP server (`aiosmtpd`, a widely used reference-grade Python SMTP implementation) instead of the sink above: ``` Error: Can't send mail - all recipients were rejected: 501 Syntax: RCPT TO: [SP ] code: 'EENVELOPE', responseCode: 501, command: 'RCPT TO', rejected: [ '[email protected](x)evil.com' ] ``` So against a strict receiver the immediate, concretely demonstrated outcome is that the message is bounced: an ordinary-looking recipient address that a sender/application believ…

Related

Weakness · CWE (2)

  • CWE-20 Improper Input Validation weakness
  • CWE-436 Interpretation Conflict weakness

References