To reset a password is an authenticated operation and requires that the user has identified themselves in a secure manner. Usually it is done with a user name and password plus a second factor. The user name and password are often submitted at the same time in the same HTTP request. This is not uncommon and is not a red flag.
In a forgotten password scenario, the need to authenticate the user is exactly the same. This means they are submitting their user name plus some alternative form of credentials (it sounds like, in your case, you are using challenge questions, which I shall not comment on). Other than that, it's still authentication, and it poses no problem to submit the user name and the credentials at the same time, just like with regular signon.
The problem arises when you collect the user name on a separate page. This is common for workflows involving a user-specific challenge and response (such as challenge questions but also with out-of-band OTPs) because the system needs to know the user name ahead of time so it knows what questions to display or where to send the OTP. The temptation is to collect the user name on a separate page, then pass it around as a hidden form variable. This is subject to tampering on the client side and therefore provides a vector for an IDOR attack.
The mitigation is to handle the forgotten password "session" the same way that you manage an ordinary signon session; maintain the user name in a tamper-proof fashion, such as an encrypted cookie or a session variable. Hidden fields are trivial to tamper with.