GHSA-97r5-pg8x-p63p

SECURITY_OAUTH_ENABLE = True SECURITY_OAUTH_BUILTIN_PROVIDERS = ["github"] SECURITY_FRESHNESS = timedelta(seconds=1) SECURITY_FRESHNESS_GRACE_PERIOD = timedelta(seconds=0) SECURITY_USERNAME_ENABLE = True SECURITY_CHANGE_USERNAME = True The OAuth provider was replaced with a localhost mock provider returning attacker@example.com. This avoids hitting a live third-party provider while still exercising Flask-Security-Too's real OAuth verification handler. Reproduction steps: 1. Log in as victim@example.com. 2. Wait until the session is no longer fresh. 3. Confirm POST /change-username is blocked with 401 and reauth_required=true. 4. Start OAuth verification with POST /login/oauth-verify-start/ github. 5. Complete the callback with an OAuth identity for attacker@example.com. 6. Confirm the session is still for victim@example.com, but fs_paa has been updated. 7. Retry POST /change-username. 8. The victim user's username is changed successfully. Observed result: { "pre_bypass_status": 401, "pre_bypass_reauth_required": true, "attacker_identity": "attacker@example.com", "oauth_verify_response_status": 302, "post_bypass_change_username_status": 200, "final_email": "victim@example.com", "final_username": "victimowned1777878574", "direct_impact_verified": true } Note: CSRF was disabled in the local harness only to keep the test focused on the reauthentication check. This is not a CSRF bypass report. This bypasses Flask-Security-Too's freshness/reauthentication boundary. Applications using OAuth verification together with freshness- protected account operations may allow a stale victim session to be refreshed using a different user's OAuth account. In my test, this allowed the victim account's username to be changed through Flask- Security-Too's built-in /change-username route. A likely fix is to reject OAuth verification unless the resolved OAuth user matches current_user before updating session["fs_paa"].