Many thanks for the detailed report, I'm looking into it.

I had a look and can confirm the issue.

In fact it's even worse than you describe, because it is actually possible to reset the password of any user that has a pending TOKEN_ACCOUNT_VERIFY, without the attacker even owning an account, using a brute-force approach calling account_update.php with increasing user IDs with a simple request like so:

curl -X POST http://example.com/mantisbt/account_update.php --data 'verify_user_id=XXX&password=NEW_PWD&password_confirm= NEW_PWD'

For the record, even after this vulnerability is fixed, it will not be possible to be 100% bulletproof in a password reset/account creation scenario - if the attacker somehow obtains the confirmation hash, they will be able to reset the target user's password and there is nothing we can do about it (referring to point 2 of your steps to reproduce).

I agree with you, if the attacker gains access to the confirmation_hash, then the account is highly likely to be compromised. What I'm concerned about in the 2nd step of step to reproduce is if the link got "accidentally opened" without changing the actual password, then the account will have the pending TOKEN_ACCOUNT_VERIFY.

However, I believe it should be sufficient to include the confirmation_hash or a similar validation during password reset / registration, it can help to determine whether the current request is authorized to perform password changes for the given user_id.

I believe it should be sufficient to include the confirmation_hash or a similar validation during password reset / registration

Yep, this is precisely how I was planning to address this issue.

We use Github advisories to handle CVE requests and code review for security fixes. Please let me know your Github user id, so I can grant you access to a private fork for you to review and test the patch.

Sure, my Github user id is 54769255 (https://github.com/redna-xela)

my Github user id is 54769255

Thanks, I actually meant username, not id, sorry ;-)

I added you to the Github Advisory GHSA-93x3-m7pw-ppqm. You will also find a proposed patch there. Please review, feedback is welcome.

Thank you, I'll look into this and get back to you as soon as possible.

Thanks for waiting! I've reviewed the patches, and everything looks good. I've also confirmed that the previous vulnerability is no longer exploitable.

Thanks for the feedback, that was quick :-)
Are you also happy with the advisory's wording, CVSS evaluation and selected CWE ?

I'm now waiting for a CVE ID to be assigned.

Thanks for asking. The advisory's wording, CVSS evaluation and selected CWE already looks good to me, but I would like to suggest the following if possible:

• Impact: "A successful attack could grant the attacker full access to the compromised account, including sensitive information or functionalities associated with the account" or something similar.
• CVSS Scoring: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L
• Workarounds: I think it's better if we provide the workaround according to what has been done, which is by adding additional validation to the /account_update.php

For the CVSS scoring, I believe the impact could be worse depending on who uses it and what kind of data is being stored, hence the C:H and I:H. Attack Complexity changed to High because successful attack cannot be accomplished at will, but rather need some perquisites to be fulfilled.

I appreciate any feedback you may have.

Impact: "A successful attack could grant the attacker full access to the compromised account, including sensitive information or functionalities associated with the account"

OK sounds good.

C:H and I:H

This is somewhat subjective, and as you say depends on external factors, in particular the access level of the account that gets hijacked.
I did not want to paint things too black considering that the probability of a successful attack is quite low

Attack Complexity changed to High because successful attack cannot be accomplished at will, but rather need some perquisites to be fulfilled.

I set it to low initially, because a brute-force attack can be launched at will and very easily, as explained in 0034433:0068886, even if the probability of success would be very low without some preparation work (e.g. social engineering to trick users so there are actual requests pending). Someone could just get lucky...

provide the workaround according to what has been done, which is by adding additional validation

The idea was to have a quick and simple to implement option to reduce the risk, until a patch was available.

I guess the point is kind of moot, as I would make the Advisory public together with the patch and 2.26.2 release, so anyone could either a) upgrade or b) apply the patch.

Thanks for your input! I'm on board with you regarding the CVSS Scoring, I guess it would be better to use the previous score you've provided to avoid inflating the perceived risk. I also see your point about the workaround section, we can leave it as is.

I think that's all, no further feedback from me based on what we've discussed :)

Great, thanks for your collaboration.
I reverted the CVSS change, now back to 7.3 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

CVE-2024-34077 assigned