Attack Chain

1. An attacker identifies a target's email address and crafts a malicious version by inserting a Unicode homoglyph character that resembles '@' (e.g., victim_email[U+XXXX]attacker.com).
2. The attacker submits this crafted email address to the vulnerable Auth.js application's magic-link sign-in flow.
3. The application's default normalizeIdentifier function validates the address, incorrectly perceiving only one '@' symbol because validation occurs prior to Unicode normalization.
4. The application proceeds to send the magic-link email, with the crafted address passed to a downstream mail library or service.
5. The mail library or service, which performs Unicode normalization (e.g., NFKC) for internationalized email, processes the recipient address.
6. During normalization, the homoglyph character in the crafted email canonicalizes to a second '@' symbol (e.g., victim_email@attacker.com), causing the mail service to misroute the magic link.
7. The magic link is delivered to the attacker-controlled mailbox, enabling the attacker to authenticate and gain unauthorized access to the victim's account.

Impact

The primary impact of this vulnerability is account takeover. An attacker who knows a victim's email address can exploit this flaw to request a magic link that is subsequently delivered to an attacker-controlled mailbox. The attacker can then use this link to sign in as the victim, gaining full access to their account. No victim interaction is required for the link to be misrouted, as the attacker initiates and directly receives the authentication link. This can lead to unauthorized access to personal data, financial information, or sensitive corporate resources, depending on the scope and permissions of the compromised account.

Recommendation

• Upgrade next-auth to a patched version (currently pending, refer to GHSA-7rqj-j65f-68wh for updates) immediately.
• Upgrade @auth/core to a patched version (currently pending, refer to GHSA-7rqj-j65f-68wh for updates) immediately.
• If immediate upgrade is not possible, implement a custom normalizeIdentifier on the email provider that calls identifier.normalize("NFKC") before any validation, and ensures only one '@' remains after normalization, as detailed in the GHSA advisory.
• Alternatively, as a workaround, reject any email addresses containing non-ASCII characters if your user base does not require internationalized email addresses.