BETTER-AUTH · GHSA-hwq2-v29r-p69r · Package
FIX → 1.8.0-beta.5 +1
Email-change links in better-auth did not record which user requested the change, so a link could act on whichever account later registered the old address. An attacker who controls both addresses can take over that new account and change its email to one they control.
first public Nov 3, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications using better-auth 1.4.0 or later with user-initiated email changes enabled and email verification sending configured. The exposure needs a released email address that a new user can register while an old change link is still valid; apps without changeEmail enabled can skip it.
Not affected if changeemail-disabled, no-email-verification, pre-1.4.0
Who cares better-auth, node, self-hosted
npm ls better-authuser.changeEmail.enabled set to true in the auth configurationemailVerification.sendVerificationEmail is configuredUpgrade to 1.8.0-beta.5 +1
You are affected if you use better-auth 1.4.0 or later with all of these:
user.changeEmail.enabled is turned on.emailVerification.sendVerificationEmail is configured.An email change link recorded the old and new addresses, but not the user who asked for the change. If someone else registered the old address while the link was still valid, opening the link acted on that person's account.
A user who controls the addresses involved can take over an account that later registers their released old address, using a link issued for their own account. They get a session for that account, and its email changes to an address they control. The attack needs the victim to register the released address while one of the attacker's links is still valid.
Upgrade better-auth to 1.7.16, or to 1.8.0-beta.5 on the beta line.
Email verification and change links now work only for the account they were issued to. Opening a change link no longer signs the user in, and it marks the new address verified only if the current one was verified.
Turn off user-initiated email changes until you upgrade. A lower shortens the window but does not stop the attack.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
better-auth 1.4.0 up to but not including 1.7.16: move to 1.7.16better-auth 1.8.0-beta.0 up to but not including 1.8.0-beta.5: move to 1.8.0-beta.5emailVerification.expiresIn does not stop the attackemailVerification.expiresInThe change link carried the old and new addresses. Without a session, Better Auth looked up the account that owned the old address at that moment, created a session for it, and changed its email. The link now carries the requesting user's ID and is rejected for any other account.