{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.0.8"
      },
      "package": {
        "ecosystem": "npm",
        "name": "nodemailer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T17:36:06Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nNodemailer 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.\n\nAn 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.\n\n### Details\nSource-to-sink evidence:\n\n- `lib/mailer/mail-message.js:241-249` calls `_getListHeaders(this.data.list)` and adds each returned value with `this.message.addHeader(listHeader.key, value)`.\n- `lib/mailer/mail-message.js:253-296` builds each list header value as `{ prepared: true, foldLines: true, value: ... }`.\n- 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.\n- For the other `List-*` headers, `lib/mailer/mail-message.js:283-288` copies `value.comment` into `(\u003ccomment\u003e)`. If `mimeFuncs.isPlainText(comment)` returns true, the value is not encoded or CRLF-normalized.\n- `lib/mime-node/index.js:323-351` accepts the prepared header object.\n- `lib/mime-node/index.js:533-540` trusts `options.prepared`; when `foldLines` is set, it pushes `mimeFuncs.foldLines(key + \u0027: \u0027 + value)` directly into the header block.\n- 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.\n- `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.\n\nDefault/common exposure evidence:\n\n- `lib/nodemailer.js:21-60` exposes the public `createTransport(...).sendMail(...)` flow used by the package.\n- `examples/full.js:106-123` documents `list.unsubscribe.comment` and `list.id.comment` as normal message options.\n- The behavior is in shipped runtime code and does not require test-only code, non-default build steps, or undocumented internals.\n\nFalse-positive screening and negative controls:\n\n- 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.\n- Ordinary `subject` header input containing CRLF was normalized to a single `Subject:` header and did not create `X-Injected` in the local control case.\n- 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.\n- `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.\n\nVariant analysis:\n\nLocal 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.\n\nAffected version evidence and uncertainty:\n\n- Confirmed vulnerable: `nodemailer` 8.0.8 at commit `15138a84c543c20aa399218534cdbbfa2ea1ce55`.\n- 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.\n- Affected range is therefore recorded as unknown beyond the confirmed current version.\n- No patched version was identified in this checkout.\n\nSeverity rationale:\n\n- AV: The vulnerable library path is reached through application-level message submission in typical networked applications that use Nodemailer.\n- AC: A single CRLF sequence in a documented message option triggers the issue.\n- 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.\n- UI: No maintainer or victim interaction is needed after the application accepts the message object.\n- S: The impact remains in the application/mail-generation security scope.\n- 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.\n- A: No availability impact was demonstrated.\n\nFinal self-review:\n\n- Reproduction evidence was generated locally from this checkout with a safe in-memory `streamTransport` PoC and a negative `Subject` control case.\n- The PoC is non-destructive and does not send network traffic outside the process.\n- The observed output contains an actual CRLF-delimited injected header line.\n- Reachability, sanitizer bypass, package exposure, variants, and non-exploitable sibling paths were checked as described above.\n- The affected range is not overclaimed; only the current tested version is confirmed vulnerable.\n\n### PoC\n\nFrom a clean checkout of `nodemailer` at commit `15138a84c543c20aa399218534cdbbfa2ea1ce55`, run:\n\n```bash\nnode \u003c\u003c\u0027NODE\u0027\n\u0027use strict\u0027;\nconst nodemailer = require(\u0027./\u0027);\nconst headersEnd = raw =\u003e raw.slice(0, raw.indexOf(\u0027\\r\\n\\r\\n\u0027));\nconst hasStandaloneInjected = raw =\u003e /\\r\\nX-Injected: yes\\)/.test(raw) || /\\r\\nX-Injected: yes\\r\\n/.test(raw);\n(async () =\u003e {\n  const transport = nodemailer.createTransport({ streamTransport: true, buffer: true });\n  const positive = await transport.sendMail({\n    from: \u0027sender@example.test\u0027,\n    to: \u0027recipient@example.test\u0027,\n    subject: \u0027control\u0027,\n    list: { unsubscribe: { url: \u0027https://example.test/u\u0027, comment: \u0027ok\\r\\nX-Injected: yes\u0027 } },\n    text: \u0027body\u0027\n  });\n  const positiveRaw = positive.message.toString(\u0027utf8\u0027);\n  console.log(\u0027POSITIVE_HAS_INJECTED=\u0027 + hasStandaloneInjected(positiveRaw));\n  console.log(\u0027POSITIVE_LIST_LINE=\u0027 + JSON.stringify(headersEnd(positiveRaw).split(\u0027\\r\\n\u0027).filter(line =\u003e /^List-Unsubscribe:|^X-Injected:/.test(line)).join(\u0027\\n\u0027)));\n\n  const control = await transport.sendMail({\n    from: \u0027sender@example.test\u0027,\n    to: \u0027recipient@example.test\u0027,\n    subject: \u0027safe\\r\\nX-Injected: no\u0027,\n    text: \u0027body\u0027\n  });\n  const controlRaw = control.message.toString(\u0027utf8\u0027);\n  console.log(\u0027CONTROL_HAS_INJECTED=\u0027 + /\\r\\nX-Injected: no\\r\\n/.test(controlRaw));\n  console.log(\u0027CONTROL_SUBJECT=\u0027 + JSON.stringify(headersEnd(controlRaw).split(\u0027\\r\\n\u0027).filter(line =\u003e /^Subject:|^X-Injected:/.test(line)).join(\u0027\\n\u0027)));\n\n  const variantKeys = [\u0027help\u0027, \u0027unsubscribe\u0027, \u0027subscribe\u0027, \u0027post\u0027, \u0027owner\u0027, \u0027archive\u0027, \u0027id\u0027];\n  const result = [];\n  for (const key of variantKeys) {\n    const info = await transport.sendMail({\n      from: \u0027sender@example.test\u0027,\n      to: \u0027recipient@example.test\u0027,\n      subject: \u0027variant \u0027 + key,\n      list: Object.assign({}, { [key]: { url: key === \u0027id\u0027 ? \u0027example.test\u0027 : \u0027https://example.test/\u0027 + key, comment: \u0027c\\r\\nX-Variant-\u0027 + key + \u0027: yes\u0027 } }),\n      text: \u0027body\u0027\n    });\n    result.push(key + \u0027=\u0027 + new RegExp(\u0027\\\\r\\\\nX-Variant-\u0027 + key + \u0027: yes\u0027).test(info.message.toString(\u0027utf8\u0027)));\n  }\n  console.log(\u0027VARIANTS=\u0027 + result.join(\u0027,\u0027));\n})().catch(err =\u003e { console.error(err \u0026\u0026 err.stack || err); process.exit(1); });\nNODE\n```\n\nObserved output in this environment:\n\n```text\nPOSITIVE_HAS_INJECTED=true\nPOSITIVE_LIST_LINE=\"List-Unsubscribe: \u003chttps://example.test/u\u003e (ok\\nX-Injected: yes)\"\nCONTROL_HAS_INJECTED=false\nCONTROL_SUBJECT=\"Subject: safe X-Injected: no\"\nVARIANTS=help=true,unsubscribe=true,subscribe=true,post=true,owner=true,archive=true,id=true\n```\n\nExpected 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.\n\nCleanup: none required; the PoC uses only in-memory message generation.\n\n### Impact\n\nA 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.\n\n### Suggested remediation\n\nNormalize 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.",
  "id": "GHSA-268h-hp4c-crq3",
  "modified": "2026-06-15T17:36:06Z",
  "published": "2026-06-15T17:36:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/security/advisories/GHSA-268h-hp4c-crq3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodemailer/nodemailer"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nodemailer: CRLF injection in Nodemailer List-* header comments allows arbitrary message header injection"
}