GHSA-7rqj-j65f-68wh — Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass

Affected: npm: @auth/core, npm: next-auth

## Summary

The default email-address normalizer used by the email/magic-link sign-in flow validates the address **before** applying Unicode normalization. An address can contain a Unicode character that is not an ASCII `@` (U+0040) but canonicalizes to one under NFKC/NFKD normalization (the normalization commonly applied by mail libraries and services for internationalized email). Such an address passes the normalizer's single-`@` check, but a downstream mail library that normalizes the string then sees two `@` separators and may deliver the passwordless sign-in link to a different recipient than intended. This is an instance of validating before canonicalizing.

## Am I affected?

You may be affected if **all** of the following hold:

- You use `next-auth` `>= 4.0.0, < 4.24.14`, or `@auth/core` `>= 0.1.0, < 0.41.3`. - You have the email / magic-link (passwordless) provider enabled. - You rely on the built-in default identifier normalizer (you have not supplied your own `normalizeIdentifier`). - Your `sendVerificationRequest` implementation uses a mail library or delivery service that applies Unicode normalization to recipient addresses (most internationalized-email/SMTPUTF8-capable senders do).

You are **not** affected if you do not use the email provider, or if your normalizer/mailer rejects or canonicalizes non-ASCII addresses before they are validated.

## Impact

- Account takeover: an attacker who knows a victim's email address can request a magic link that is delive…

Most recent entries from all

GHSA-7rqj-j65f-68wh — Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass