Vulnerabilities

Security incident · GHSA-8xp8-xrh2-88vr

Public registration sends the verification email to the submitted address instead of the matched account

Published Sep 2, 2026 · catalog updated Sep 2, 2026 · Public registration sends the

Last checked Nov 1, 2026. A connected source was read within the last 7 days.

Open the advisory

Exploitation likelihood is not on this record for GHSA-8xp8-xrh2-88vr. A missing EPSS score is not a low risk. Compare Public registration sends the with the linked advisory before you change production.

Severity

Medium5.3

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

Awaiting synchronization with FIRST

Remediation

Version ranges on file

Affected products

npm directus

## Summary Public registration resolves existing accounts with a case-normalized email comparison, but it builds the email verification token and selects the email recipient from the address exactly as submitted in the request. On MySQL and MariaDB, whose default collations are accent insensitive, an accented variant of an existing address matches that account's row while the verification link is delivered to the mailbox of the submitted variant. This separates the account that gets verified from the address that receives the verification link. ## Details Registration matches an existing account with a lowercased comparison against the stored email. When a matching account is found and its status is , the request is treated as a verification resend rather than rejected. The token payload and the mail recipient are then taken from the submitted address rather than from the account that was matched, and the verification endpoint resolves the address in the token back to an account through the same collation-sensitive comparison. Under an accent-insensitive collation, and are the same row for the lookup and two different mailboxes for delivery. An attacker registers the victim's canonical address, which creates an unverified account with a password the attacker chooses, then registers an accented variant of that same address. The second request matches the account created by the first, takes the resend path because the account is still unverified, and mails a verification link addressed to the accented variant, which the attacker controls. Following that link resolves back to the account holding the victim's canonical address and activates it. This was confirmed against MariaDB 11.8.8 with no collation configured, where the server default is and the accented variant matches the stored canonical address. PostgreSQL, SQLite and SQL Server do not compare accented characters as equal under their default collations, so those deployments are not affected. The related email c