🔐 Account Takeover Risk: An attacker who gains access to a valid session (e.g., via XSS, local device compromise, stolen session cookie) can change the account email and lock out the legitimate owner from recovery flows.

🔁 Recovery & MFA Bypass: Changing the email may reroute password reset and recovery messages to an attacker-controlled address, allowing full takeover even if MFA is enabled on other factors.

🎯 Privilege & Trust Escalation: Email is often used as the primary identity and for privileged actions (billing, admin changes); changing it silently transfers control.

🔍 Audit & Compliance Failures: Unauthorized changes to account identity attributes undermine logs and non-repudiation, creating regulatory risks.

📉 Reputational & Business Damage: Customer trust suffers if accounts can be hijacked without password confirmation.

💼 Enterprise Risk: Compromised corporate accounts may expose internal systems, code, or customer data.

💸 Financial Loss & Fraud: Attackers could use control of accounts for fraudulent transactions or social-engineering attacks.

⚖️ Regulatory Exposure: Unauthorized account modifications may trigger breach reporting obligations and compliance penalties.

🛠️ Operational Cost: Incident response, rollback, token revocation, and customer support escalate operational expense.

🔍 Brand Damage: Loss of confidence in account security harms retention and acquisition.

Vector: AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N

Score: 7.4 — High

The email-change endpoint trusts the authenticated session (cookie / bearer token) as sufficient proof of identity and does not require entering the current password or performing a re-authentication step.

No step verifying possession of the current password, primary email, or another active authentication factor before applying the change.

Weak session management (long-lived sessions, no device or IP re-check) increases exposure.

Application may rely solely on client-supplied parameters or allow CSRF/CSRF-protected flows to complete without strong protections.

Lack of secondary confirmation to the existing email to confirm the requested change.

Require Current-Password Re-Authentication

    Before accepting an email change, require the user to re-enter their current password (or perform re-authentication via the primary auth method). This is standard for sensitive account modifications.

Confirm Request via Existing Email

    Send a confirmation to the current email (not the requested new email) containing a one-time confirmation link or code. Only apply the change after the current email owner confirms.

Dual-Opt-In (New Email Verification)

    Send a verification to the new email as well. Do not switch the account’s primary email until the new email is verified and the existing email has acknowledged the change, or until re-authentication has occurred.

Require Stronger Auth for High-Risk Accounts

    For accounts with elevated privileges or sensitive data, require additional factors (e.g., MFA confirmation, OTP) before permitting email changes.

Rotate/Invalidate Recovery Secrets

    After email change, rotate session tokens, invalidate password-reset tokens bound to the old email, and force re-login across active sessions.

Implement Rate-Limiting & Abuse Detection

    Detect multiple email-change attempts, rapid changes, or changes from new devices/IPs and flag for review or require additional verification.

CSRF Protection & SameSite Cookies

    Ensure CSRF protections are in place for the email-change endpoint and that session cookies use appropriate SameSite attributes.

Audit & Notifications

    Log email-change requests with details (actor user id, IP, user agent, timestamp). Immediately notify the old email and the account owner of the change with instructions to revert if unauthorized.

Short Window for Pending Changes

    If using a “pending change” model (change only after confirmations), expire pending requests quickly (e.g., 1 hour) and mark them single-use.

User requests email change to [new@example.com](mailto:new@example.com).

Server requires re-authentication: prompt user to enter current password (or validate recent MFA). Reject if incorrect.

Server sends confirmation email to current email: We received a change request to [new@example.com](mailto:new@example.com) — confirm to proceed. Include one-time link.

Server sends verification email to new email containing verification link/code.

Only after (a) current-email confirmation or successful re-authentication and (b) new-email verification are changes applied. On apply: mark tokens used, invalidate active sessions, rotate recovery tokens, and notify both emails of completion.