Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm
Not in CISA KEV

CVE-2026-90776 — nodemailer

Fix: nodemailer/nodemailer@c07f175

CVE-2026-90776 is a CWE-407 vulnerability in nodemailer. A fix is available for nodemailer — see the affected versions and patch details below.

Nodemailer 9.1.0 through 10.0.4 Denial of Service via Quadratic Address Parsing

Also known asGHSA-prgh-xp8r-p3m5
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 26, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-90776.

EPSS Exploitation Probability

via FIRST.org ↗
0.7%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs52th percentile — riskier than 52% of all scored CVEsHighest risk
0.18%0.52%0.85%1.18%0.7%0.7%Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

11Kother npm packages depend on this — each one inherits the vulnerability until it's patched upstream
nodemailernpm
29.5Mdownloads / week

Description

Summary

nodemailer/lib/addressparser parses one shape of address in O(n^2) time. A single ~640 KB address value blocks the Node.js event loop for roughly 7 seconds. And it is reachable without auth: mailparser feeds inbound email headers straight into this parser, so one crafted email is enough to stall a service that parses mail.

Details

The parser builds a single address by accumulating its atoms into one string. When the atoms are separated by RFC 5322 comments, like a@b(c)@b(c)@b(c)..., every atom re-joins that same growing string.

The join check in src/addressparser/index.ts:

const joins =
    prevToken &&
    prevToken.noBreak &&
    parts.length &&
    (prevToken.value !== ')' || parts[parts.length - 1].slice(-1) === '@' || token.value.charAt(0) === '@');

The issue is the order of the last two operands. parts[parts.length - 1].slice(-1) runs before the cheap token.value.charAt(0). slice(-1) has to flatten the accumulator to read its last character → O(current length) → and that runs on every token → O(n^2) over the whole value. Since || is left to right, the cheap charAt(0) that would short-circuit never gets the chance.

The chain: long comment-joined address → one growing accumulator → slice(-1) re-flattens it on every token → quadratic parse time.

PoC

Isolated, just the parser (npm i [email protected]):

const addressparser = require('nodemailer/lib/addressparser');
const s = Date.now();
addressparser('a' + '@b(c)'.repeat(130000));
console.log(Date.now() - s, 'ms'); // ~7000 ms, blocking

End to end through mailparser, the remote path (npm i [email protected]):

const { simpleParser } = require('mailparser');
(async () => {
  const to = 'a' + '@b(c)'.repeat(130000);
  const eml = `From: [email protected]\r\nTo: ${to}\r\nSubject: x\r\n\r\nhi\r\n`;
  const s = Date.now();
  await simpleParser(eml);
  console.log(Date.now() - s, 'ms'); // ~7000 ms, blocking
})();

Timings measured on 10.0.3:

Address valueParse time
390 KB1.3 s
585 KB5.6 s
640 KB6.7 s
976 KB18 s

It survives RFC 5322 folding: fold the header at offsets that are a multiple of the atom length and every )+@ junction stays intact, so the payload is a standards-compliant email with lines under 998 octets and still triggers it.

Impact

Algorithmic-complexity DoS. Node is single threaded, so the block stalls everything else in the process, and a handful of these back to back keeps a service down.

Affected: anything that runs addressparser on attacker-controlled input, either the public export directly or address headers built from user input. The unauthenticated remote case is mailparser. 3.9.24 pins nodemailer 10.0.3 and calls the parser on inbound To/From/Cc with no length cap, so any service parsing inbound mail with it can be frozen by a single email.

Suggested fix

Swap the last two operands so the cheap check runs first:

(prevToken.value !== ')' || token.value.charAt(0) === '@' || parts[parts.length - 1].slice(-1) === '@')

Pure boolean commutation, so the parse output is identical. Verified byte for byte on the test inputs, and the full 1276-test suite passes.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npmnodemailer≥ 9.1.0&&< 10.0.510.0.5npm install nodemailer@10.0.5

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nodemailer, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update nodemailer to 10.0.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-90776 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

This is an Important denial of service vulnerability in Nodemailer's email address parsing component. A remote, unauthenticated attacker can send specially crafted email headers to applications utilizing Nodemailer, leading to excessive CPU consumption and blocking the Node.js event loop. This can cause a temporary…

Workaround published by Red Hat
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Source: Red Hat security advisory for CVE-2026-90776 (CC BY 4.0)

Frequently Asked Questions

### Summary `nodemailer/lib/addressparser` parses one shape of address in O(n^2) time. A single ~640 KB address value blocks the Node.js event loop for roughly 7 seconds. And it is reachable without auth: mailparser feeds inbound email headers straight into this parser, so one crafted email is enough to stall a service that parses mail. ### Details The parser builds a single address by accumulating its atoms into one string. When the atoms are separated by RFC 5322 comments, like `a@b(c)@b(c)@b(c)...`, every atom re-joins that same growing string. The join check in `src/addressparser/index
O3 Security · Impact-Aware SCA

Is CVE-2026-90776 in your dependencies?

Find it across npm, including transitive dependencies.

CVE-2026-90776: nodemailer DoS — Fixed in 10.0.5