Nodemailer npm: A Security Review and Safe Usage Guide

The nodemailer npm package is safe and well maintained on current versions, but email sending is an injection-prone operation, so how you build messages and which version you pin both matter. Nodemailer is the de facto library for sending email from Node.js — roughly 4 million weekly downloads — and it has a solid security track record. The risks worth knowing are the handful of CVEs patched across recent releases, the header- and content-injection surface that comes with any email library, and a fake package that impersonated it. This review covers all three and gives you a safe-usage checklist.

What nodemailer is and why it is everywhere

Nodemailer sends email over SMTP (and other transports) from Node.js with a small, dependency-light API. You create a transport, hand it a message object, and call sendMail:

const nodemailer = require('nodemailer');

const transport = nodemailer.createTransport({
  host: 'smtp.example.com',
  port: 587,
  secure: false,        // upgrade to TLS via STARTTLS
  auth: { user: process.env.SMTP_USER, pass: process.env.SMTP_PASS },
});

await transport.sendMail({
  from: 'app@example.com',
  to: recipient,
  subject: 'Welcome',
  text: body,
});

If you search npm nodemailer you will find it under its longtime maintainer, actively released. That maturity is a point in its favor: it is patched promptly and has a clear security policy.

Known vulnerabilities in nodemailer

Like any long-lived library, nodemailer has accumulated advisories, and the pattern is reassuring — real issues, fixed quickly, in the releases that followed. Worth knowing:

• CVE-2020-7769 — command injection. Older versions were vulnerable to command injection through the sendmail transport when addresses were not properly escaped. It was fixed in 6.4.16. If you are anywhere below that, upgrade immediately.
• CVE-2025-14874 — denial of service. The address parser could be driven into excessive recursion by a crafted address, enabling a DoS. The fix requires upgrading to a patched 7.0.x release or later.
• Interpretation conflict in address parsing. A separate issue involved improper handling of quoted local-parts containing @, which could cause mail to route to unintended external recipients or bypass domain-based access controls. Addressed in a later 7.0.x release.
• CRLF injection via envelope size. A carriage-return/line-feed injection path through an envelope parameter was fixed in the 8.0.x line.

None of these are the library doing something reckless; they are the kind of parsing edge cases that any mail library has to defend against. The practical takeaway is to stay current — the latest release at the time of writing is 9.0.3 — and pin the exact version in your lockfile.

npm install nodemailer@latest
npm ls nodemailer   # confirm the resolved version

The fake nodemailer package

There is a supply-chain footnote worth flagging. In 2025, a malicious package (nodejs-smtp) was published to impersonate nodemailer, mimicking its API and README to trick developers into installing it. The payload targeted cryptocurrency wallets on the victim's machine. This was not a flaw in nodemailer itself — it was typosquatting that exploited nodemailer's popularity. The defense is the same as for any npm nodemailer install: confirm you are pulling the exact package name from the correct maintainer, and let an SCA tool watch for known-malicious packages entering your tree. Our 10 npm security best practices cover typosquatting defenses in detail.

The real risk: email injection in your own code

Most email security bugs are not in nodemailer — they are in how applications assemble messages from user input. Two patterns to guard against:

Header injection. If you build recipient lists, subjects, or reply-to values by concatenating user input, an attacker who slips a newline into that input can inject additional headers — adding Bcc recipients, spoofing From, or splitting the message. Nodemailer's structured message object mitigates a lot of this because you pass fields as properties rather than assembling a raw header block, but you still must validate any address that originated from a user:

// validate before it reaches the message object
if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(recipient)) {
  throw new Error('Invalid recipient');
}

HTML content injection. If you send HTML email that includes user-provided content, treat it exactly like web output: sanitize it. An email client is a rendering surface, and unsanitized user content in an HTML body is a phishing and content-spoofing vector against your recipients.

Never let a user control the from address of transactional mail, and never build the SMTP configuration from request data.

A safe-usage checklist

• Pin the latest nodemailer version and keep it current; you inherit every parsing fix that way.
• Store SMTP credentials in environment variables or a secrets manager, never in source.
• Use TLS (secure: true on port 465, or STARTTLS on 587); do not send credentials over plaintext SMTP.
• Validate every user-supplied address and reject anything containing control characters or newlines.
• Sanitize any user content that goes into an HTML body.
• Rate-limit the endpoints that trigger email so a compromised form cannot be turned into a spam relay.

An SCA tool can confirm the nodemailer version in your lockfile is above the patched thresholds and alert you if a future advisory lands or a malicious lookalike appears.

FAQ

Is the nodemailer npm package safe to use?

Yes, on a current version. Nodemailer is actively maintained and patches issues promptly. Pin the latest release (9.0.3 at the time of writing), keep it above CVE-2020-7769's 6.4.16 fix, and validate user input.

What are the main nodemailer vulnerabilities?

Historically a sendmail command injection (CVE-2020-7769, fixed in 6.4.16), an address-parser denial of service (CVE-2025-14874), an address interpretation conflict, and a CRLF injection via envelope size. All are fixed in later releases.

Is there a fake nodemailer package on npm?

Yes. A malicious typosquat (nodejs-smtp) impersonated nodemailer in 2025 to target crypto wallets. Confirm the exact package name and maintainer, and use a scanner that flags known-malicious packages.

How do I prevent email injection with nodemailer?

Validate every user-supplied address and reject newlines or control characters, pass fields through nodemailer's structured message object rather than raw headers, sanitize any user content in HTML bodies, and never let users control the from address or SMTP config.