Thanks for the bug report; I confirm the behavior - even worse for me, after submitting the attack bugnote on my dev box, the whole Issue won't render at all.

Please let me know how you would like to be credited for the finding, and also your Github user id so I can add you to the security advisory for review and tests.

Hi dregad,

Thank you for confirming the issue. I’m glad the report was helpful.

For credit, you can attribute the finding to:
Name: Mazen Mahmoud
GitHub ID: TheAmazeng

regards,
Mazen

Security advisory created https://github.com/mantisbt/mantisbt/security/advisories/GHSA-r3jf-hm7q-qfw5
CVE ID requested.

CVE-2025-46556 assigned

Started working on the fix.

To make things simpler, I'm planning to set a hardcoded limit for long text fields. I believe 64K chars would be an acceptable value; for comparison, Jira has a jira.text.field.character.limit setting for this, defaulting to 32767 chars (reference).

I'm not sure it's worth adding a new config option for this - thoughts appreciated @vboctor @atrol.

This should apply to textarea fields, and related back-end functions for: bugnotes, Issue description, steps_to_reproduce and additional_information for sure.

Other fields may be worth considering as well:

• news.body
• project.description
• project_version.description
• user_profile.description
• tag.description
• custom_field.text

Probably not necessary since they are not end-user input (or used by administrator): config.value, filters.filter_string, tokens.value, email.metadata and email.body

The limit of Azure DevOps is a lot higher.
Getting the following message when trying to add a large note

TF401262: Value of long text field Microsoft.VSTS.TCM.ReproSteps exceeds the maximum allowed length of 1048576.

I'm not sure it's worth adding a new config option for this -

Having a configuration option / function similar to $g_max_file_size / file_get_max_file_size() would be good.
I would introduce it as a global setting, use config_get_global().
I suspect $g_max_file_size uses config_get() just due to historical reasons.

Other fields may be worth considering as well:

To prevent DoS, at least the following fields should be protected, as they can be entered by non-admin / non-manager users.

• user_profile.description
• custom_field.text

@dregad I would apply a single limit to all the affected fields you listed. I'm OK with having it as a global config as @atrol suggested (e.g., $g_max_textarea_length). But I'm also OK with not having a config option initially (just a constant) and adding it later if we get feedback that it is needed. I assume the limit will not impact values already in the DB and will only impact new additions.

What I would avoid is spamming configs with a limit per entity.

Thanks both for your feedback

The limit of Azure DevOps is a lot higher [...] maximum allowed length of 1048576

That's 1 MiB, much too high IMHO, as only 4 notes with this size will be enough to achieve the same DoS attack reported in the original post.

Having a configuration option / function similar to $g_max_file_size / file_get_max_file_size() would be good.
I would introduce it as a global setting, use config_get_global().

OK I will amend my patch to switch from constant to config.

at least the following fields should be protected, as they can be entered by non-admin / non-manager users.

• user_profile.description
• custom_field.text

Agreed. Will include those in the patch.

What I would avoid is spamming configs with a limit per entity.

I was definitely not planning to add multiple configs for this, it would not add any value.