CVE-2025-47776

Mantis Bug Tracker (MantisBT) is an open source issue tracker. Due to incorrect use of loose (==) instead of strict (===) comparison in the authentication code in versions 2.27.1 and below.PHP type juggling will cause certain MD5 hashes matching scientific notation to be interpreted as numbers. Instances using the MD5 login method allow an attacker who knows the victim's username and has access to an account with a password hash that evaluates to zero to log in without knowing the victim's actual password, by using any other password with a hash that also evaluates to zero This issue is fixed in version 2.27.2.

Mantis Bug Tracker (MantisBT) is an open source issue tracker. Due to incorrect use of loose (==) instead of strict (===) comparison in the authentication code in versions 2.27.1 and below.PHP type juggling will cause certain MD5 hashes matching scientific notation to be interpreted as numbers. Instances using the MD5 login method allow an attacker who knows the victim's username and has access to an account with a password hash that evaluates to zero to log in without knowing the victim's actual password, by using any other password with a hash that also evaluates to zero This issue is fixed in version 2.27.2.

Due to an incorrect use of loose (==) instead of strict (===) comparison in the authentication code, PHP type juggling will cause interpretation of certain MD5 hashes as numbers, specifically those matching scientific notation.

Impact

On MantisBT instances configured to use the MD5 login method, user accounts having a password hash evaluating to zero (i.e. matching regex ^0+[Ee][0-9]+$) are vulnerable, allowing an attacker knowing the victim's username to login without knowledge of their actual password, using any other password having a hash evaluating to zero, for example comito5 (0e579603064547166083907005281618).

No password bruteforcing for individual users is needed, thus $g_max_failed_login_count does not protect against the attack.

Patches

• https://github.com/mantisbt/mantisbt/commit/966554a19cf1bdbcfbfb3004766979faa748f9a2

Workarounds

Check the database for vulnerable accounts, and change those users' passwords, e.g. for MySQL:

SELECT username, email FROM mantis_user_table WHERE password REGEXP '^0+[Ee][0-9]+$'

References

• https://mantisbt.org/bugs/view.php?id=35967

Credits

Thanks to Harry Sintonen / Reversec for discovering and reporting the issue.

Mantis Bug Tracker (MantisBT) is an open source issue tracker. Due to incorrect use of loose (==) instead of strict (===) comparison in the authentication code in versions 2.27.1 and below.PHP type juggling will cause certain MD5 hashes matching scientific notation to be interpreted as numbers. Instances using the MD5 login method allow an attacker who knows the victim's username and has access to an account with a password hash that evaluates to zero to log in without knowing the victim's actual password, by using any other password with a hash that also evaluates to zero This issue is fixed in version 2.27.2.

Mantis Bug Tracker (MantisBT) is an open source issue tracker. Due to incorrect use of loose (==) instead of strict (===) comparison in the authentication code in versions 2.27.1 and below.PHP type juggling will cause certain MD5 hashes matching scientific notation to be interpreted as numbers. Instances using the MD5 login method allow an attacker who knows the victim's username and has access to an account with a password hash that evaluates to zero to log in without knowing the victim's actual password, by using any other password with a hash that also evaluates to zero This issue is fixed in version 2.27.2.

Due to an incorrect use of loose (==) instead of strict (===) comparison in the authentication code, PHP type juggling will cause interpretation of certain MD5 hashes as numbers, specifically those matching scientific notation.

Impact

On MantisBT instances configured to use the MD5 login method, user accounts having a password hash evaluating to zero (i.e. matching regex ^0+[Ee][0-9]+$) are vulnerable, allowing an attacker knowing the victim's username to login without knowledge of their actual password, using any other password having a hash evaluating to zero, for example comito5 (0e579603064547166083907005281618).

No password bruteforcing for individual users is needed, thus $g_max_failed_login_count does not protect against the attack.

Patches

• https://github.com/mantisbt/mantisbt/commit/966554a19cf1bdbcfbfb3004766979faa748f9a2

Workarounds

Check the database for vulnerable accounts, and change those users' passwords, e.g. for MySQL:

SELECT username, email FROM mantis_user_table WHERE password REGEXP '^0+[Ee][0-9]+$'

References

• https://mantisbt.org/bugs/view.php?id=35967

Credits

Thanks to Harry Sintonen / Reversec for discovering and reporting the issue.