Due to incorrect use of "==" comparison in the authentication code [1], certain passwords will match others, and allow logging in without knowledge of the user's actual password. This is due to the PHP "type juggling", that is in effect when "==" is used instead of "===" for comparison.

"If both operands are numeric strings, or one operand is a number and the other one is a numeric string, then the comparison is done numerically. These rules also apply to the switch statement. The type conversion does not take place when the comparison is === or !== as this involves comparing the type as well as the value." [2]

Since == is incorrectly used in the authentication, certain MD5 hashes are actually interpreted as numbers. For this comparison to occur in a meaningful way for the attacker, a certain passwords would need to be used that evaluate to 0. For this to happen the MD5 hash must match scientific notation, in specific "<zerodigits>e<decimaldigits>". Here are some example passwords that evaluate to 0:

0e579603064547166083907005281618 - comito5
000e3929732265082641653087610392 - 5vIibvvE
0e372829928149377848243830057478 - qfusapu
0e939903558056676963775753908726 - embracive93
00e68920418794764838006365853524 - dab7agn1
0e650184638565677195827290878196 - unp0p322
0000e123872474818172583283659121 - sj79b6tt
0e140982361523351164051745201801 - galactia2005
000e5644860322972252624896726221 - al-9cq21

Note that there are zero digits, then 'e', followed by more decimal digits. When interpreted this always leads to value 0. Notably 0 == 0 comparison is true.

Now, to be actually exploitable the victim user needs to use one of the passwords that evaluate to 0 when interpreted in scientific notation. To exploit these vulnerable passwords, the attacker needs to only know the usernames of the victims (which they can try to guess). The attacker can use any of the passwords that evaluate to 0, for example "comito5" (0). If the victim user has a password that is vulnerable the login succeeds. No password bruteforcing for individual users is needed, and thus g_max_failed_login_count does not protect against the attack.

I have not calculated how many percent of passwords will hit these special values. The number is not very high, but isn't insignificant either. Whether individual password is affected or not can be checked by inspecting the MD5 hash it results to. If it matches the pattern described above, the password is vulnerable.

Fixing this vulnerability is easy: use "===" in the comparison.

[1] https://github.com/mantisbt/mantisbt/blob/0fb502dd613991e892ed2224ac5ea3e40ba632bc/core/authentication_api.php#L782
[2] https://www.php.net/manual/en/language.operators.comparison.php