NextAuth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass
28Vexday Risk Score
No sign of exploitation. No public exploitation artifact known so far.
ssvc Trackcvss 9.1epss 0.5%
exploitation probability
0.5%top 56% of all CVEs
observed exploitation
nono source reports it
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.
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
References
https://github.com/nextauthjs/next-auth/commit/19d2feb24359fa8c79418907fc68d9ec8152ca94https://github.com/nextauthjs/next-auth/commit/a63eee12a1a20cb35209e44195b097868517b9a0https://github.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3https://github.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32https://github.com/nextauthjs/next-auth/security/advisories/GHSA-7rqj-j65f-68wh