Most recent entries from all

Withdrawn: CLEANSTART-2026-BG21634 — Security fixes in langfuse-worker 3.216.0-r1

Withdrawn by the publisher.

Affected: CleanStart: langfuse-worker

Package langfuse-worker version 3.216.0-r1 fixes 29 vulnerabilities: ghsa-frvp-7c67-39w9, ghsa-p63j-vcc4-9vmv, ghsa-55q2-fjhq-7xh7, ghsa-c2j3-45gr-mqc4, CVE-2026-69192...

EUVD-2026-352458

fkie_cve-2026-73420

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.

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…