GHSA-268h-hp4c-crq3

What it actually does

Nodemailer versions before 8.0.9 improperly validate carriage-return and line-feed characters in comments used for List-* email headers. If an application passes attacker-controlled data into these List-* header comment fields, an attacker can break out of the intended header line and inject additional arbitrary RFC 5322 message headers. This can alter message routing, add recipients, change reply handling, influence downstream mail processing, or interfere with security controls that rely on trusted message headers. The issue requires application-level reachability: exploitation depends on whether untrusted input is used to construct Nodemailer List-* headers.

Why it matters to the business

Successful exploitation can cause an application to send emails with attacker-injected headers, potentially leading to unauthorized recipients, misleading reply paths, phishing enablement, privacy leakage, mail delivery issues, or damage to email trust and brand reputation. This is a medium-severity supply-chain issue in the npm ecosystem; it is not currently listed in CISA KEV and no mature exploit is reported, but affected applications that generate mailing-list or notification emails from user-controllable fields should be prioritized for upgrade.

How an attack unfolds

An attacker identifies an application feature that sends email through Nodemailer and allows user-controlled content to influence List-* header comments, such as mailing-list metadata, unsubscribe/help text, group names, campaign labels, or notification descriptors. The attacker submits a crafted value containing CRLF characters followed by a new header name and value. When the vulnerable Nodemailer version builds the message, it fails to neutralize the CRLF sequence in the List-* comment context, causing the mail header block to contain attacker-supplied additional headers. The resulting email is then handed to the SMTP server or mail transport with the injected headers intact, where downstream mail infrastructure and clients may process them as legitimate message metadata.

How to fix it

Upgrade Nodemailer to version 8.0.9 or later. For npm-based projects, update package.json and the lockfile, then rebuild and redeploy all services that bundle Nodemailer. Where direct upgrade is not immediately possible, prevent untrusted input from reaching Nodemailer List-* header comment fields and reject or strip carriage return and line feed characters from all values used in email headers. Prefer allowlists for header values, avoid constructing email headers from free-form user input, and ensure centralized email-sending helpers enforce RFC-safe header encoding.

How to confirm the fix worked

Confirm that the deployed dependency tree resolves Nodemailer to 8.0.9 or later using commands such as `npm ls nodemailer`, `npm audit`, or lockfile inspection. Verify all built artifacts, containers, serverless bundles, and deployed packages include the fixed version, not only source repositories. Add a regression test that attempts to pass CRLF-containing input into List-* header comment values and confirm the generated raw message contains no attacker-created additional headers. Review package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, or yarn.lock for older transitive copies of Nodemailer.

Typical attack path

1. Find an application endpoint or workflow that sends email using Nodemailer.
2. Identify a field that is reflected into List-* header comments, such as list metadata or unsubscribe/help-related labels.
3. Submit a value containing CRLF characters followed by a crafted email header.
4. Trigger the application to send the email.
5. Nodemailer constructs the message and injects the attacker-controlled header into the RFC 5322 header block.
6. Downstream SMTP servers, mail filters, or recipients process the injected header as part of the message.

How to detect it

Look for evidence in application logs, request logs, mail generation logs, SMTP transaction logs, outbound mail archives, and raw RFC 5322 message captures. Focus on workflows that populate List-* headers and inspect whether user-supplied values contain raw or URL-encoded CRLF sequences. Search outbound messages for unexpected headers appearing immediately after List-* headers, duplicate or anomalous Bcc/Cc/Reply-To/Sender/Return-Path headers, unusual List-Unsubscribe/List-Help/List-Id formatting, or mail sent to recipients not expected by the application workflow. If raw message archives are available, compare generated headers against the application’s intended template. Also review web/API requests shortly before suspicious outbound emails for `%0d%0a`, `%0D%0A`, `\r\n`, or header-like strings embedded in parameters that influence email metadata.

• %0d%0aBcc:
• %0D%0ABcc:
• %0d%0aCc:
• %0D%0ACc:
• %0d%0aReply-To:
• %0D%0AReply-To:
• %0d%0aSender:
• %0D%0ASender:
• %0d%0aReturn-Path:
• %0D%0AReturn-Path:
• %0d%0aFrom:
• %0D%0AFrom:
• \r\nBcc:
• \r\nCc:
• \r\nReply-To:
• \r\nSender:
• \r\nReturn-Path:
• \r\nFrom:
• List-Unsubscribe:
• List-Help:
• List-Id:

What your security team should do

• Inventory all applications and services using the npm package `nodemailer`.
• Prioritize applications that send user-facing email, mailing-list email, campaign email, notifications, password/account emails, or messages where users can influence labels, group names, display text, or list metadata.
• Upgrade Nodemailer to 8.0.9 or later and redeploy affected services.
• Add input validation that rejects CR, LF, and encoded CRLF sequences in any value used to construct email headers.
• Review recent outbound email samples and mail logs for signs of unexpected headers or anomalous recipients.
• Add regression tests and SAST rules to prevent direct use of untrusted input in email header construction.