Back to Blog
high SEVERITY7 min read

CVE-2025-14874: Nodemailer DoS via Crafted Email Address Header Parsing

A high-severity Denial of Service vulnerability (CVE-2025-14874) was discovered in Nodemailer versions prior to 7.0.11, where a specially crafted email address header could cause the application to hang or crash. The fix involved a major version bump from Nodemailer 6.10.1 to 7.0.11 in the `Dise-ador-experto-master/package-lock.json` dependency file. Left unpatched, this vulnerability could allow any unauthenticated attacker to disrupt email-sending functionality and potentially take down the en

O
By orbisai0security
May 31, 2026

CVE-2025-14874: How a Crafted Email Address Header Could Bring Down Your Nodemailer App

Introduction

The package-lock.json file inside Dise-ador-experto-master quietly locked the project to Nodemailer 6.10.1 — a version that harbors a high-severity Denial of Service (DoS) vulnerability tracked as CVE-2025-14874. This isn't a theoretical edge case: Nodemailer's email address header parser contains a flaw that allows a malicious actor to supply a specially crafted To:, From:, Cc:, or similar header value that causes the parser to enter a pathological processing state, consuming CPU or memory until the Node.js process becomes unresponsive or crashes entirely.

For any application that passes user-controlled input — such as a "send to" field in a contact form or an invitation system — into Nodemailer's address parsing pipeline, this vulnerability is directly exploitable without authentication.


The Vulnerability Explained

What Goes Wrong in Nodemailer 6.x

Nodemailer's address parser is responsible for taking strings like:

"John Doe" <john.doe@example.com>, jane@example.com

...and turning them into structured address objects. The parser in the 6.x branch handles complex, nested, or malformed address strings using logic that, under certain crafted inputs, can exhibit catastrophic backtracking or an unbounded processing loop.

A crafted payload might look something like:

"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@" <x>

or involve deeply nested comment structures within the RFC 5321/5322 address format, such as:

((((((((((((((((((((user))))))))))))))))))))@example.com

When Nodemailer 6.10.1's parser encounters these inputs, it does not impose a hard limit on processing time or recursion depth. The result is that the event loop — Node.js's single-threaded heart — blocks completely while the parser grinds through the malformed input.

The Attack Surface in This Project

In the Dise-ador-experto-master application, Nodemailer is used as a direct dependency for sending emails (e.g., contact forms, notifications, or user-facing email dispatch). Any code path that accepts user input and passes it to transporter.sendMail() is vulnerable:

// Example vulnerable pattern in a Node.js/Express route
app.post('/contact', async (req, res) => {
  const { recipientEmail, subject, body } = req.body;

  // ⚠️ recipientEmail is user-controlled and passed directly
  // to Nodemailer 6.10.1's address parser — CVE-2025-14874
  await transporter.sendMail({
    from: 'app@example.com',
    to: recipientEmail,   // <-- malicious input enters here
    subject: subject,
    text: body,
  });

  res.send('Email sent!');
});

An attacker submitting a crafted value for recipientEmail triggers the vulnerable parser. Because Node.js is single-threaded, a blocked event loop means no other requests are served until the parser finishes — which, in the worst case, it never does. The entire application becomes unavailable.

Real-World Impact

Scenario Impact
Public contact form Attacker sends one request → entire app goes down
Email invitation system Attacker floods endpoint → sustained DoS
Internal tooling Insider threat or compromised client crashes the service
Serverless (Lambda/Cloud Functions) Function times out, incurring cost and availability loss

This is classified high severity because it requires no authentication, no special privileges, and only a single HTTP request to execute.


The Fix

What Changed

The remediation is a direct major version upgrade of the nodemailer package:

Package:  nodemailer
Before:   6.10.1   (vulnerable)
After:    7.0.11   (patched)
Strategy: Major version bump (6.x  7.x)
File:     Dise-ador-experto-master/Dise-ador-experto-master/package-lock.json

Before vs. After in package-lock.json

Before (vulnerable):

"nodemailer": {
  "version": "6.10.1",
  "resolved": "https://registry.npmjs.org/nodemailer/-/nodemailer-6.10.1.tgz",
  "integrity": "sha512-<old-hash>"
}

After (patched):

"nodemailer": {
  "version": "7.0.11",
  "resolved": "https://registry.npmjs.org/nodemailer/-/nodemailer-7.0.11.tgz",
  "integrity": "sha512-<new-hash>"
}

Why Version 7.x Fixes the Problem

Nodemailer 7.x rewrites the address header parsing logic with explicit input validation and processing limits. The new parser:

  1. Caps recursion depth when handling nested comment structures in RFC 5322 addresses.
  2. Enforces a maximum address string length before parsing begins.
  3. Uses iterative parsing for certain constructs that previously relied on potentially unbounded recursive calls.
  4. Rejects malformed inputs early rather than attempting to normalize them through expensive processing.

The net effect is that a crafted address that would previously block the event loop for seconds (or indefinitely) is now rejected in microseconds with a structured error that the application can catch and handle gracefully.

Handling the Major Version Bump

Because this is a 6.x → 7.x upgrade, developers should verify compatibility. Key things to check:

// Verify your transporter creation still works in v7
const nodemailer = require('nodemailer');

const transporter = nodemailer.createTransport({
  host: 'smtp.example.com',
  port: 587,
  secure: false,
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS,
  },
});

// In v7, sendMail still returns a Promise — no API breakage for common usage
const info = await transporter.sendMail({ ... });

Check the Nodemailer 7.x migration guide for any deprecated transport options or configuration changes that may affect your specific setup.


Prevention & Best Practices

1. Validate Email Addresses Before Passing to Nodemailer

Add a validation layer so malformed inputs never reach the parser:

const { validate } = require('email-validator'); // or use validator.js

app.post('/contact', async (req, res) => {
  const { recipientEmail } = req.body;

  // Validate before passing to Nodemailer
  if (!validate(recipientEmail)) {
    return res.status(400).json({ error: 'Invalid email address' });
  }

  await transporter.sendMail({ to: recipientEmail, ... });
});

2. Keep package-lock.json Under Version Control and Audit Regularly

The vulnerability lived in a locked dependency version. Use automated tooling to catch this:

# Run npm audit in CI/CD
npm audit --audit-level=high

# Or use a dedicated tool
npx better-npm-audit audit

3. Enable Dependabot or Renovate Bot

Automate dependency updates so vulnerabilities like CVE-2025-14874 are patched within hours of disclosure, not weeks.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/Dise-ador-experto-master"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

4. Wrap Email Sending in a Timeout

As a defense-in-depth measure, wrap sendMail calls with a timeout to limit blast radius even if a parser issue is discovered in the future:

const sendWithTimeout = (mailOptions, timeoutMs = 5000) => {
  return Promise.race([
    transporter.sendMail(mailOptions),
    new Promise((_, reject) =>
      setTimeout(() => reject(new Error('Email send timeout')), timeoutMs)
    ),
  ]);
};

5. Relevant Security Standards

  • OWASP A06:2021 – Vulnerable and Outdated Components: This is a textbook example of the risk of using unpatched third-party libraries.
  • CWE-400: Uncontrolled Resource Consumption: The root cause classification for this DoS vulnerability.
  • CWE-20: Improper Input Validation: The upstream parser failed to validate and reject malformed address inputs.

Key Takeaways

  • User-controlled email addresses must be validated before reaching Nodemailer's parser — even a single unvalidated to: field in a contact form was enough to trigger CVE-2025-14874.
  • Locking to nodemailer@6.10.1 in package-lock.json meant the project was silently exposed — always treat your lock file as a security artifact, not just a reproducibility tool.
  • The fix required a major version bump (6.x → 7.x), which means this class of DoS was significant enough to warrant a breaking-change release cycle — treat major security fixes with the same urgency as minor patches.
  • A single malicious HTTP request with no authentication could block the Node.js event loop entirely, making this a low-effort, high-impact attack against any publicly accessible endpoint using Nodemailer 6.x.
  • Defense-in-depth matters: Even after upgrading to 7.0.11, adding input validation with email-validator and a sendMail timeout provides layered protection against future parser vulnerabilities.

Conclusion

CVE-2025-14874 is a sharp reminder that third-party email libraries — often treated as "set it and forget it" infrastructure — can carry serious security debt. In the Dise-ador-experto-master project, the Nodemailer 6.10.1 lock in package-lock.json created a direct path for an unauthenticated attacker to crash the application with a single crafted email address string. The fix — upgrading to Nodemailer 7.0.11 — patches the address header parser to reject malicious inputs before they consume unbounded resources.

Beyond applying this specific patch, the lesson for every Node.js developer is clear: treat your package-lock.json as a living security document, automate dependency audits in your CI/CD pipeline, and never pass user-controlled strings to third-party parsers without first validating their format. A few lines of input validation can be the difference between a resilient application and one that falls to a single HTTP request.


This vulnerability was automatically detected and remediated by Orbis AppSec. For continuous dependency monitoring and automated security fixes, explore our platform.

View the Security Fix

Check out the pull request that fixed this vulnerability

View PR #10

Related Articles

high

CVE-2025-14874: Nodemailer DoS via Crafted Email Address Headers

A high-severity denial-of-service vulnerability (CVE-2025-14874) was discovered in Nodemailer 6.10.1, where an attacker could craft a malicious email address header to crash or hang the mail-sending process. The fix involved a direct major version upgrade from 6.10.1 to 7.0.7 in the project's `package-lock.json`, closing the attack vector entirely. Applications relying on Nodemailer for transactional or user-triggered email are at risk until this upgrade is applied.

high

CVE-2025-14874: Nodemailer DoS via Crafted Email Address Header

A high-severity denial-of-service vulnerability (CVE-2025-14874) was discovered in Nodemailer versions prior to 7.0.0, where a specially crafted email address header could cause the application to hang or crash. The fix involved upgrading Nodemailer from version 6.10.1 to 7.0.7 in the `Dise-ador-experto-master` project's `package-lock.json`. This major version upgrade closes the attack surface and ensures email processing remains stable under adversarial input.

high

CVE-2025-14874: Nodemailer DoS via Crafted Email Address Header

CVE-2025-14874 is a high-severity Denial of Service vulnerability in Nodemailer that allows an attacker to crash an application by sending a specially crafted email address header. The vulnerability existed in Nodemailer versions prior to 7.0.11 and was present in the `Dise-ador-experto-master` project's `package-lock.json` dependency on version 6.10.1. Upgrading to Nodemailer 7.0.11 resolves the issue by fixing the underlying header parsing logic that could be exploited to cause unbounded resou

high

Authorization Bypass in gRPC-Go HTTP/2 Path Validation (CVE-2026-33186)

A critical authorization bypass vulnerability (CVE-2026-33186) in `google.golang.org/grpc` v1.79.1 allowed attackers to circumvent gRPC authorization policies through malformed HTTP/2 path values. The fix upgrades the dependency in `src/go/go.mod` from v1.79.1 to v1.79.3, closing a path validation gap in the `grpc-go/authz` middleware that could have exposed protected RPC endpoints to unauthorized callers.

high

CVE-2026-41676: OpenSSL Bindings Vulnerability Fixed in Rust SDK Cargo.lock

A high-severity vulnerability (CVE-2026-41676) was discovered in the `rust-openssl` crate (version 0.10.73) used in the `apps/rust-sdk` component, as flagged by the Trivy scanner in `Cargo.lock`. The fix upgrades the `openssl` crate from `0.10.73` to `0.10.80` and `openssl-sys` from `0.9.109` to `0.9.116`, closing an exploitable attack surface in production code that handles user-influenced input. Because the Rust SDK sits in the production codebase, any attacker able to reach the OpenSSL code p