next-auth Magic Link Misdelivery: CVE-2026-73420 Explained (2026)

There have now been three separate advisories about next-auth delivering a magic link to somebody who did not ask for it. The 2022 one, the 2025 one, and CVE-2026-73420 in July.

Here is the part worth your attention. Each fix is where the next bug lives.

Am I affected

npm ls next-auth @auth/core

You are in the published affected ranges if you are on:

• next-auth >= 4.10.3 and < 4.24.15
• next-auth >= 5.0.0-beta.1 and <= 5.0.0-beta.31
• @auth/core >= 0.1.0 and < 0.41.3

That last floor is worth reading twice. @auth/core 0.1.0 shipped in December 2022, so "every version before 0.41.3" means every version there has ever been.

You also have to be using the email or magic-link sign-in path. If your app is OAuth-only, this specific advisory is not yours to worry about.

The bug, precisely

The default normalizer trims the address, counts @, and refuses anything that does not have exactly one. Here it is as shipped in next-auth 4.24.12, comments included:

const normalizer: (identifier: string) => string =
  provider.normalizeIdentifier ??
  ((identifier) => {
    const trimmedEmail = identifier.trim()

    // Validate email format according to RFC 5321/5322
    // Reject emails with quotes in the local part to prevent address parser exploits
    // Reject multiple @ symbols which could indicate an exploit attempt
    const atCount = (trimmedEmail.match(/@/g) ?? []).length
    if (atCount !== 1) {
      throw new Error("Invalid email address format.")
    }
    // ...

"Reject multiple @ symbols which could indicate an exploit attempt." The check does exactly that, and the attack is built so that at the moment of counting there is only one.

U+FF20 FULLWIDTH COMMERCIAL AT is a different codepoint from U+0040. The regex /@/g does not match it. But under NFKC normalization, the form mail libraries apply when they handle internationalized addresses, it folds into a plain ASCII @.

So the string is valid on the way in and a different string on the way out.

We ran the shipped normalizer against three payloads to see which survive:

"victim@example.com,attacker@evil.com"    -> REJECTED: Invalid email address format.

"victim@example.com<U+FF20>attacker.evil"
   accepted as -> "victim@example.com＠attacker.evil"
   after NFKC   -> "victim@example.com@attacker.evil"   | @ count: 2
   domain a last-@ parser delivers to -> attacker.evil

"victim@example.com<U+FE6B>attacker.evil"
   accepted as -> "victim@example.com﹫attacker.evil"
   after NFKC   -> "victim@example.com@attacker.evil"   | @ count: 2
   domain a last-@ parser delivers to -> attacker.evil

Two things fall out of that. The 2022 comma payload is genuinely dead, so the older fix works. And the advisory names U+FF20 as the example, but it is not the only one: U+FE6B SMALL COMMERCIAL AT folds to the same character and behaves identically. Anything that NFKC-folds to @ is a candidate.

The chain, which is the actual story

We bisected the published tarballs to find where each check entered the code. The dates are the npm publish times.

Three advisories, three fixes, and the same shape each time: a string check added in front of a mail library that parses addresses by different rules. Every fix closed the exact input that got reported. None of them closed the gap between what the validator thinks the address says and what the sender thinks it says.

That gap has a name. CWE-180, "Incorrect Behavior Order: Validate Before Canonicalize." Canonicalize first, then validate, and all three bugs disappear at once. That is what 4.24.15 finally does.

What being on an affected version does not tell you

The exploit needs a second thing your version number cannot answer: your mail sender has to normalize the recipient address.

The advisory says senders that handle internationalized email commonly apply NFKC. It does not name one. That uncertainty is encoded right in the CVSS vector as AT:P, attack requirements present.

We have since measured one of them. Nodemailer does not normalize: we passed the fullwidth U+FF20 payload through nodemailer 9.0.0 and 9.1.0 and the character survived untouched in both, so the address never gains a second separator and the chain does not complete. If you use the Nodemailer provider, this attack is not your exposure. The full test, and the two separate nodemailer domain-parsing bugs we found along the way, are written up separately. Resend, SendGrid and Postmark are still unmeasured, so treat those stacks as unknown rather than safe.

There is also no public evidence anyone has exploited it. No proof of concept shipped with the advisory, which is a contrast with the 2025 misdelivery bug that did ship one, and it is not on CISA's Known Exploited Vulnerabilities list.

None of that is a reason to stay unpatched. It is a reason not to tell your users you were breached.

If you want to know rather than assume, send yourself one:

// Send to an address containing U+FF20 at a domain you control.
// If it arrives at the SECOND domain, your sender normalizes.
const probe = "you@your-domain.test＠second-domain-you-own.test";

await mailer.send({ to: probe, subject: "normalization probe", text: "arrived" });

Use two domains you actually own. Never point a probe at somebody else's.

Fix it

normalizeIdentifier(identifier: string) {
  // Canonicalize FIRST. This is the whole fix.
  const email = identifier.normalize("NFKC").toLowerCase().trim();

  if (email.includes('"')) throw new Error("Invalid email address format.");
  if ((email.match(/@/g) ?? []).length !== 1) {
    throw new Error("Invalid email address format.");
  }
  // Optional, and worth it if you do not need international addresses:
  if (/[^\x20-\x7E]/.test(email)) throw new Error("Invalid email address format.");

  return email;
}