NextAuth.js CVE-2026-73420

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.

The vulnerability affects the NextAuth.js / Auth.js ecosystem: npm package @auth/core versions >= 0.1.0 and < 0.41.3 (fixed in 0.41.3), npm package next-auth versions >= 4.10.3 and < 4.24.15 (fixed in 4.24.15), and the v5 line next-auth >= 5.0.0-beta.1 through <= 5.0.0-beta.31 (fixed in 5.0.0-beta.32). Only deployments that enable the email/magic-link (passwordless) provider, rely on the built-in default identifier normalizer instead of a custom normalizeIdentifier, and use a sendVerificationRequest mailer/service that applies Unicode normalization are actually exploitable. No CPE strings were provided in the input. The authoritative vendor advisory is GHSA-7rqj-j65f-68wh (https://github.com/nextauthjs/next-auth/security/advisories/GHSA-7rqj-j65f-68wh).