Password reset endpoint leaks account existence via timing side-channel

Hi,

A recent penetration test against our tenant flagged a timing-based user enumeration issue on:

  • POST /dbconnections/change_password
  • POST /u/reset-password/request/Username-Password-Authentication

Finding: Both valid and invalid email addresses return HTTP 200 with the same generic “Check Your Email” page and message, so there’s no content-based leak. However, response times differ consistently and measurably:

  • Valid, existing email: ~130–260ms

  • Non-existent email: ~260–370ms

    I know Attack Protection covers brute force, suspicious IP throttling, bot detection, and breached password detection, but none of those address timing-based enumeration specifically.

Questions:

  1. Is this a known issue with these endpoints? Is equalized/constant-time response handling on Auth0’s roadmap here?
  2. Is there any tenant-side configuration (Actions, custom domain settings, etc.) that can influence response timing before the initial reset-request response is sent, given that the Post Challenge Action trigger only fires after the email challenge is completed?

Any guidance — official or from others who’ve hit this in a pentest — would be appreciated. Happy to open a support ticket too if this needs to go through Auth0 security directly.