Severity: CRITICAL
Location: src/Controllers/AuthController.php:589-594
Bug: handleForgotPassword sets $_SESSION['reset_user_id'] for any registered email. showResetPassword only checks the session key is present — not that the code was delivered or entered.
Fix: Do not set reset_user_id until the code is verified; use a signed nonce for the intermediate step.
Status: open. Will reply with remediation details when resolved.
Resolved.
Hardened the password-reset flow in src/Controllers/AuthController.php:
handleForgotPassword now calls session_regenerate_id(true) before stashing any reset state. Any session that may have been fixed against the anonymous browser is discarded the moment a reset is requested.reset_user_id, the session now holds a short-lived HMAC nonce (reset_nonce) and an expiry (reset_expires_at, 15 min). showResetPassword and handleResetPassword both check that all three are present and that the deadline hasn't passed, wiping the state otherwise.verification_codes remains the gating factor, but the flow now needs all three to proceed: valid session cookie + live nonce + correct emailed code.This doesn't replace the email-link-token pattern (that would be a bigger UX change), but closes the cross-session contamination angle the reviewer flagged: a different browser that picks up a victim's cookie can no longer walk through the reset form because the nonce is tied to the rotated session id.
Locking this thread.