[finding] change-email verifies only the NEW address, so a hijacked session can move the account identity without the old mailbox ever being told

[huangyiirene]

Filed by the domain:identity seat (#6022) out of PR #8017's review, on that dev's reported option B. Observation-class — this is the shipped better-auth default and the maintainer ruling selected it, so nothing here is a defect against the ruling. Recording the exposure so it does not evaporate into a closed thread. Unassigned; triage grades it.

What ships now

PR #8017 enabled user.changeEmail per the 2026-08-12 ruling, which said 「策略按 better-auth 常规」. The dev established what 常规 means in the installed version (1.7.0-rc.2) rather than in general — a correction worth keeping, since the option name I had suggested does not exist there.

The resulting flow is single-step: the verification token rides emailVerification.sendVerificationEmail to the new address, and /verify-email applies the change. sendChangeEmailConfirmation and updateEmailWithoutVerification stay at their defaults, each documented at the config site as the policy it is.

The exposure

The old mailbox is never contacted. So an attacker holding a live session — stolen cookie, unattended device, session not yet revoked — can:

1. POST /change-email to an address they control;
2. verify it from that address;
3. own the account's identity, with the original owner's mailbox receiving nothing.

The account-recovery path then belongs to the attacker. Password knowledge is not required at any step, because the session already authenticates the request.

Why this is a finding and not a queue card:

• it is better-auth's default and the ruling explicitly selected 常规;
• no measured incident, no user report;
• the fix is not free — sendChangeEmailConfirmation means a new email template plus its i18n bundle keys in all four locales, i.e. a new authoring surface, not a config flip;
• and it interacts with work already in flight: session revocation now tombstones rather than deletes (session-list-revoke: sys_session.revoked_at/revoke_reason are declared readonly "System-managed" but the interactive-revoke path deletes rather than tombstones — ADR-0069 D4 revoke-audit trail is effectively inert #7732), so "was the session still valid" became an answerable question that it was not before.

The mitigation, if it is ever graded up

sendChangeEmailConfirmation gives the two-step shape: the old address approves first, then the new one verifies. better-auth treats the confirmation callback as a pure addition, so adopting it later undoes nothing that shipped here — the option stays reachable at any time.

⚠️ Do not read this as a defect in #8017

The PR implemented the ruling correctly and documented both withheld options at the config site with their reasons, rather than leaving them as unexplained defaults. That documentation is what makes this finding cheap to act on later. If triage grades this up, the work is a follow-up card against the policy, not rework against that PR.

Related

#7735 / PR #8017 (the enablement and the documented withheld options) · #7732 (session tombstoning — makes session validity auditable) · #7724 / PR #7879 (the admin deletion path, whose brokenness was the other half of #7735's ruling)

[hotlong]

Triage (findings round): graded — held as finding.

Why held: the current flow is better-auth's default and the 2026-08-12 maintainer ruling explicitly selected 常规, so changing it is a policy revision, not a repair — and the cost side is real (a new email template + i18n bundle keys in all four locales = a new authoring surface). No measured incident, no user report. Under startup scope discipline this stays recorded, not queued, and it does not enter the decision inbox while symptom-free.

What makes this cheap to act on later is already in place (the PR documented both withheld options at the config site), and the card's own mitigation path (sendChangeEmailConfirmation — old address approves first) is purely additive, so nothing shipped forecloses it. Re-grade triggers: (1) any account-takeover incident or credible report involving change-email; (2) the maintainer revisiting auth policy for enterprise/compliance reasons — this card should ride that review; (3) the security posture of session theft changing materially (e.g. #7732's tombstones surfacing evidence that live-session abuse is occurring).

---

Generated by Claude Code

[hotlong]

Finding-grading round: escalated to needs-user-decision (domain:identity).

Premise re-verified verbatim on origin/main: changeEmail: { enabled: true } (auth-manager.ts:975-977) with both better-auth hardening options deliberately left default — per a maintainer ruling made today (#7735 / PR #8017, 「策略按 better-auth 常规」). Adopting old-address confirmation would reverse that ruling, change user-visible flow semantics, and add a new email template + i18n keys in 4 locales (new authoring surface) — maintainer floor on all three counts.

Question: should change-email require confirmation from the OLD address (or at minimum notify it), given a hijacked session can currently move the account identity silently?

Four-prong analysis:

• Platform long-term coherence: old-address notification is the industry-standard control for exactly this attack; better-auth ships it as a config flag (sendChangeEmailConfirmation), so adopting it is configuration, not architecture.
• Measured business pull: no incident measured; the exposure is real but theoretical today (requires an already-hijacked session).
• AI-agent error-resistance: neutral — this is a human-attacker control, not an authoring-surface question.
• Startup scope discipline: notify-only (no confirmation gate) is the cheaper half; full confirmation adds template + flow + 4-locale i18n as permanent surface. Deferring entirely is also defensible given today's ruling.

Recommendation: notify-the-old-address only (no blocking confirmation) as a middle path — it defeats silent identity movement at minimal surface cost; #7732's session tombstoning makes "was the session live" answerable for incident response. But since this reverses a same-day ruling, it is the maintainer's call in both directions.

---

Generated by Claude Code

[hotlong]

Maintainer ruling — 2026-08-12 (live PM chat, session_01GxKQfv3k8b6a2d2QrZU411; maintainer sam, verbatim: 「接受你的全部建议。」 accepting the decision-box analysis in full). Moved out of the decision box → pm:queue.

Ruling: notify the OLD address — do not gate on it. A change-email flow sends a notification to the previous address; the change itself still completes on the new address's verification alone. This is the middle path: it defeats silent identity movement by a hijacked session while adding no blocking step and no new confirmation gate.

Relationship to the same-day #7735 ruling (「策略按 better-auth 常规」, PR #8017): that ruling stands for the confirmation option (sendChangeEmailConfirmation remains off — we are not adding an approval gate on the old mailbox). This ruling adds only the notification. If better-auth cannot notify without also gating, report the fork rather than adopting the gate — ⛔ do not silently turn on confirmation.

Scope: new email template + i18n keys in the 4 supported locales; the notification must state what changed, the new address, and a support path — but ⛔ must not embed an undo/rollback link (that is a new flow and a new decision). Verification: change email on a test account, assert the old mailbox receives the notice and the flow completes unblocked.

---

Generated by Claude Code