GIVE YOUR AGENT THE EVIDENCE

Set up in your agent.

One prompt to get started. Paste it into your coding agent to connect cve.new through MCP and bring vulnerability context into your workflow.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

GIVE YOUR AGENT THE EVIDENCE

Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

Check your stack
GHSA-4v8w-gg5j-ph37critical9.1

MantisBT vulnerable to authentication bypass for some passwords due to PHP type juggling

Impact

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

Source excerpt · OSV

Affected packages

Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.

Affected rangeRecorded fix
Earlier releases before 2.27.2Ecosystem versions2.27.2

Version evidence: OSV · GHSA-4v8w-gg5j-ph37

View original version evidence (72 explicit versions)

Original source description

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

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

Credits

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

References