Auth.js Email Normalizer Unicode Homoglyph Bypass – Validate-Before-Canonicalize Logic Flaw

Vulnerability Description

This is a validation-order logic flaw in the email address normalizer used by Auth.js's email/magic-link (passwordless) authentication flow. The vulnerability exists because the normalizer validates the email structure (specifically, checking for exactly one @ symbol) before applying Unicode normalization (NFKC/NFKD). A Unicode character exists that is not the ASCII @ (U+0040) but canonicalizes to it under standard normalization schemes. An attacker can craft an email like victim+attacker@example.com where the @ is replaced with such a homoglyph, passing the pre-normalization validation. However, when downstream mail libraries apply normalization (as SMTPUTF8-capable systems do), the address becomes syntactically valid with two @ symbols, causing the magic link to be delivered to an attacker-controlled mailbox instead of the victim.

PoC Significance and Preconditions

The PoC demonstrates a real-world attack chain: it proves that Unicode normalization disparities between validation and delivery layers create exploitable gaps. The attack is reliable when all conditions align: (1) Auth.js version in vulnerable range, (2) email provider enabled with default normalizer, (3) downstream mailer applies Unicode normalization. This is not theoretical—most modern mail systems supporting internationalized email (SMTPUTF8) perform normalization automatically, making this attack surface present in many deployments. An attacker with knowledge of a victim's email address can request a passwordless sign-in link that routes to their own mailbox, gaining account access without credentials.

Detection Guidance

Log Indicators:

• Passwordless sign-in requests with non-ASCII characters in the email field (monitor for Unicode escapes like %E2 or \u sequences in logs)
• Magic-link delivery logs showing mismatched To: addresses between Auth.js records and actual SMTP transactions
• Email validation logs that accept an address, then mail library rejects or rewrites it
• Discrepancies between normalized and unnormalized email addresses in authentication audit trails

Detection Strategy:

• Implement pre-validation normalization: normalize before validation, not after
• Log all Unicode characters in email fields; flag non-ASCII @-like characters
• Compare stored email vs. actual recipient in delivery logs; alert on mismatch
• Monitor for accounts receiving magic links they did not request

Mitigation Steps

Immediate Patching:

• Upgrade next-auth to ≥ 4.24.14 or @auth/core to ≥ 0.41.3

Workarounds (if immediate upgrade is blocked):

• Implement a custom normalizeIdentifier function that applies Unicode normalization (NFKC or NFKD) before validation, rejecting any address with non-ASCII characters in critical positions
• Validate that final normalized email contains exactly one @ and no other homoglyphs
• Configure mail library to reject non-ASCII email addresses or normalize them before sending
• Add a secondary check: after the mailer processes the address, verify the recipient matches the authenticated identity

Hardening:

• Restrict email provider to ASCII-only addresses (reject internationalized domains until fully vetted)
• Implement per-domain normalization policies
• Log and alert on all non-ASCII email attempts

Risk Assessment

Likelihood of Exploitation in the Wild: Medium-High. This vulnerability requires attacker knowledge of victim email + ability to request a sign-in link, but no special tools. The Unicode homoglyph is reproducible and documented in security literature. Attackers interested in account takeover (phishing, credential stuffing, targeted compromise) would find this attractive.

Threat Actor Interest: High. Nation-state and cybercriminal groups targeting high-value accounts (business, government, finance) via OAuth/passwordless flows would prioritize this. The attack is stealthy—victims may not detect magic-link misdirection without audit log review.

Prevalence: Widespread risk among organizations using next-auth or @auth/core with email providers, especially those with users in non-ASCII email domains (China, Russia, Middle East, etc., where Unicode email addresses are common).

CVSS Implications: While no CVE was assigned, the impact warrants CVSS 8.0+ (High) due to unauthenticated account takeover potential, though exploitation requires email knowledge and active attacker involvement.