Skip to main content
← All vulnerabilities
CVE-2026-73420GHSA-7RQJ-J65F-68WH

NextAuth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass

Published
Last modified
published
Not listed in CISA KEV
Fix
Fixed in 4.24.15, 5.0.0-beta.32, 0.41.3
None on Exploit-DB, Metasploit or GitHub
  • Exploitation: none
  • Automatable: yes
  • Technical impact: total

Summary

NextAuth.js provides authentication for Next.js. Prior to @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, the defaultNormalizer used by the email and magic-link sign-in flow validates an address before applying Unicode normalization. An address can contain a Unicode character such as U+FF20 FULLWIDTH COMMERCIAL AT that is not ASCII at-sign but canonicalizes to an ASCII at-sign under NFKC or NFKD normalization. The address passes the normalizer's single-at-sign check, but a downstream sendVerificationRequest mail library or delivery service that normalizes the address can then see two at-sign separators and deliver the passwordless sign-in link to an attacker-controlled recipient. Applications are affected when the email provider uses the built-in normalizer rather than a custom normalizeIdentifier and the downstream sender applies Unicode normalization. An attacker who knows a victim's email address can request the misrouted magic link and sign in as the victim without victim interaction. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32.

Timeline

  1. CVE published
  2. CISA SSVC assessment

    Exploitation: none · Automatable: yes · Technical impact: total

  3. Record last updated

Affected versions

  • nextauthjs next-auth

    fixed in 4.24.15; From 5.0.0-beta.4 · fixed in 5.0.0-beta.32

  • @auth core

    From 0.1.0 · fixed in 0.41.3

  • @auth/corenpm

    From 0.1.0 · fixed in 0.41.3

  • next-authnpm

    From 4.10.3 · fixed in 4.24.15

  • next-authnpm

    From 5.0.0-beta.1 · fixed in 5.0.0-beta.32

References 6

GitHub · nextauthjs/next-auth