GitHub Advisoryadvisory · npm
GHSA-268h-hp4c-crq3 Nodemailer: CRLF injection in Nodemailer List-* header comments allows arbitrary message header injection
MEDIUM
Official page ↗
- Ecosystem
- npm
- Packages
- nodemailer
- Severity
- Moderate
- CVSS vector
- CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
- Weaknesses
- CWE-93
- Reviewed
- 2026-06-15
Affected packages
• npm nodemailer: < 8.0.9 → fixed in 8.0.9
Description
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 `()`. 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:
```bash
node 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:
```text
POSITIVE_HAS_INJECTED=true
POSITIVE_LIST_LINE…
Related
Weakness · CWE (1)
- CWE-93 Improper Neutralization of CRLF Sequences weakness