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.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| nextauthjs | next-auth | affected |
|
|||||||||
| @auth | core | affected |
|
No data.
No data.
No data.
Project Subscriptions
No data.
Advisories
| Source | ID | Title |
|---|---|---|
 Github GHSA |
GHSA-7rqj-j65f-68wh | Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Thu, 13 Aug 2026 22:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | NextAuth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass | |
| Weaknesses | CWE-180 | |
| References |
|
|
| Metrics |
cvssV4_0
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: GitHub_M
Published:
Updated: 2026-08-13T22:04:15.414Z
Reserved: 2026-08-12T14:32:11.795Z
Link: CVE-2026-73420
Vulnrichment
No data.
NVD
Status : Received
Published: 2026-08-13T22:17:26.297
Modified: 2026-08-13T22:17:26.297
Link: CVE-2026-73420
Redhat
No data.
OpenCVE Enrichment
No data.
Weaknesses