Suppose as A, I decide I wanted to go reset my password instead. More often than not, it will be sent to A's email address, a link that enable user A to reset my password. In other times, they may even allow other means as well such as mobile phone or messenger, but the concept is still pretty much the same, except it just complicate the trace hiding part sometimes.
Now, after A check the email and a link will appear. If the link is embedded in HTML, uncode it and look for something like this:
Now. isn't that cute. But what we are interested is the UID most of the time. And I don't need to point finger at what sort of program usually have this type of parameters. Now comes the interesting part. I have a link for A to reset A's password, but what if I CAN reset B's password instead? OK, this is where the complication may or may not help. Basically what you are interested is to obtain B's UID. To my surprise, it's something more easy than you think. Some portal, you will even be able to get that from the "reset password" page, while others, its just a matter of keying in the password incorrectly once on the login page.
Now, lets UID replace. Note that if the site uses some sort of hash check on the URL, this is probably not going to work. But then again the hash is usually going to be a combination of the parameters plus some unique identifier, with some luck, you might even be able to break the hash. In one case I encounter, the hash is basically the whole URL excluding the hash=ZZZZ parameter right at the end.
Assuming its not, replace B's uid with A's uid and you are sent to the password reset page. Go ahead and don't be shy about it. After which, go back to the login page and log into B's account successfully. And B may or may not even know the password had been changed.
You may laugh and think the hack is silly. 10 sites I saw and 10 I entered within last 3 days is not so laughable. If you maintain a portal, I think you should re-look at your password reset workflow seriously.