Summary
Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass
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
sendVerificationRequestimplementation 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.
Patched version
The fix applies Unicode (NFKC) normalization before the address is validated, so homoglyph separators are collapsed and rejected up front. Upgrade to the first release containing this fix (pending; this advisory will be updated with the exact patched version before publication). No application code changes are required after upgrading.
Workarounds
If you cannot upgrade immediately:
- Supply a custom
normalizeIdentifieron the email provider that callsidentifier.normalize("NFKC")(and lower-cases/trims) before any validation, and rejects addresses that do not contain exactly one@after normalization. - Or reject any address whose local part or domain contains non-ASCII characters, if your user base does not require internationalized email addresses.
Credit
Reported by @kakashi-kx. Thank you for the responsible disclosure.
Impact
- Account takeover: an attacker who knows a victim's email address can request a magic link that is delivered to an attacker-controlled mailbox, then use it to sign in as the victim.
- No victim interaction is required to misroute the link; the attacker initiates the flow.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
@auth/core to 0.41.3 or later; next-auth to 4.24.15 or later; next-auth to 5.0.0-beta.32 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-7RQJ-J65F-68WH? GHSA-7RQJ-J65F-68WH is a critical-severity security vulnerability in @auth/core (npm), affecting versions >= 0.1.0, < 0.41.3. It is fixed in 0.41.3, 4.24.15, 5.0.0-beta.32.
- Which packages are affected by GHSA-7RQJ-J65F-68WH?
@auth/core(npm) (versions >= 0.1.0, < 0.41.3)next-auth(npm) (versions >= 4.10.3, < 4.24.15)
- Is there a fix for GHSA-7RQJ-J65F-68WH? Yes. GHSA-7RQJ-J65F-68WH is fixed in 0.41.3, 4.24.15, 5.0.0-beta.32. Upgrade to this version or later.
- Is GHSA-7RQJ-J65F-68WH exploitable, and should I be worried? Whether GHSA-7RQJ-J65F-68WH is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-7RQJ-J65F-68WH is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-7RQJ-J65F-68WH?
- Upgrade
@auth/coreto 0.41.3 or later - Upgrade
next-authto 4.24.15 or later - Upgrade
next-authto 5.0.0-beta.32 or later
- Upgrade