Fixed Password reset allowed using email of banned user


Well-known member
Affected version
2.2.10 Patch 1
Steps to reproduce:
  1. Create 2 accounts
  2. Ban account1
  3. Logout or open an incognito window and go to /lost-password/
  4. Enter the email address of account1
  5. Login as account2
  6. Visit the password reset link, that you got for account1
  7. Change the password
Result: In the change log for account1 (the banned one) you will see account2 (the one you changed the password with).

Suggested fix: Don't send password reset email if email address of banned user is used in the password rest function.

Last edited:
My 2 cents:

I don't think this is a bug, but the right behavior of the system: Why shouldn't a banned user be able reset their password in order to login and see the ban reason? 🤔 In some webmaster's eyes it may also be a privacy issue, if you enter an arbitrary email-address (without a password) and immediately get a message, that the account was banned.

The only thing that may need some attention here: Logged in users can change other users' passwords, when they have their password reset link (see steps above). This does not make sense in my eyes.
Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.12).

Change log:
In the ChangeLoggable behaviour add a new option to force a change to be from a specific user ID. In contexts where actions are performed from an email link, such as email stop or password resets, this allows us to ensure the password reset change log is attributed to the correct user.
There may be a delay before changes are rolled out to the XenForo Community.
The whole point of the password reset link is it needs to work for users are not logged in or can't log in. It's a similar thing with unsubscribe / email stop links.

If that user uses a password reset link for account1 but they are logged in as account2, the link will still work and it will make the changes to the account it was requested for (account1).

This is the expected and correct behaviour.

The extent of this fix is it now correctly logs account1 as the person who made the change rather than account2.
Top Bottom