When Gmail scans the password reset button/link, it fires two GET requests to the /password/change endpoint:

Each request triggers the MFA code generation, resulting in two codes being sent.

FusionAuth has built-in protections against email link scanners consuming codes or triggering duplicate actions. Starting with version 1.49.0, FusionAuth introduced a mandatory confirmation page that requires user interaction when a link request doesn't originate from the same browser that initiated the workflow. This prevents most link scanners (including aggressive ones like Outlook Safe Links) from consuming codes.

However, this protection may not engage if:

Add the Confirmation Required Template to Your Custom Theme — This is likely the primary fix. The confirmation required template was added in version 1.49.0 and must be manually added to custom themes. Copy it from the default theme to ensure link scanners are blocked from triggering duplicate MFA codes.

Upgrade to the Latest Version of FusionAuth, which includes the most recent fixes for link scanner issues

Review Custom Theme Modifications — Compare your theme files against the stock FusionAuth theme to ensure the state parameter and form structure haven't been altered in ways that bypass protections

Check Proxy Configuration — Ensure any proxy in front of FusionAuth is correctly forwarding cookies and not causing duplicate page renders

Test with Default Theme — Verify the issue doesn't occur with default templates to isolate whether customizations are the cause (you've already confirmed this resolves the issue)

After the first password reset attempt, browser state and cookies are properly established, preventing the duplicate request issue on subsequent attempts from the same session.

The difference between button and link behavior may be related to how your custom theme implements these elements. Buttons might use different form submission methods or lack the postMethod=true parameter that converts GET requests to POST requests (which link scanners typically don't replicate).

To accomplish IP address-based searching, you'll need to:

Alternatively, you could retrieve login records using the Search Login Records API with other criteria (like date range or user ID) and then filter the results client-side based on the ipAddress field returned in the response.

By default, FusionAuth does not log forgot password flows or distinguish between different types of password updates. However, you can track these events going forward by setting up webhooks (note: this is an Enterprise-only feature):

Note: These password-related webhooks are Enterprise features and require an Enterprise plan. Webhooks only track events going forward from when they're enabled — they cannot retroactively capture historical password reset activity. The passwordLastUpdateInstant field will still show when the password was last changed, but without the webhook, you won't have details about the method used for the change.