0037181: CVE-2026-49280: REST and SOAP APIs allows UPDATER users to change issue status despite $g_update_bug_status_threshold - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update
0037181	mantisbt	security	public	2026-05-25 08:29	2026-07-15 08:07

Reporter	mamdo	Assigned To	dregad
Priority	normal	Severity	minor	Reproducibility	always
Status	closed	Resolution	fixed
Target Version	2.28.4	Fixed in Version	2.28.4

Summary	0037181: CVE-2026-49280: REST and SOAP APIs allows UPDATER users to change issue status despite $g_update_bug_status_threshold
Description	MantisBT separates general issue updates from issue status updates. The Admin Guide documents $g_update_bug_threshold as the access level generally required to update issue content. Its default value is UPDATER. The Admin Guide separately documents $g_update_bug_status_threshold / $g_set_status_threshold as controlling the access level required to promote or change an issue to a new status after it is opened. Its default value is DEVELOPER. With default permissions, a project UPDATER should be able to update general issue fields, but should not be able to change the issue workflow status. This is also reflected by the application’s permission model: the tested UPDATER account had can_update_issue=true but can_change_status=false. However, the REST issue update endpoint accepts a status field in PATCH /api/rest/index.php/issues/{id} and changes the issue status successfully when called by an UPDATER user. This bypasses the documented $g_update_bug_status_threshold authorization boundary. The web UI also reflects the intended restriction: the UPDATER user does not have the normal status-change capability because can_change_status=false. The same status change can still be performed through the REST API.
Steps To Reproduce	Use a MantisBT instance with default thresholds: $g_report_bug_threshold = REPORTER $g_update_bug_threshold = UPDATER $g_update_bug_status_threshold = DEVELOPER Create a project. Create three users in the project: one REPORTER one UPDATER one DEVELOPER As the REPORTER user, create an issue. Confirm the UPDATER user has permission to update the issue generally, but does not have permission to change issue status: project role: UPDATER / 40 can_update_issue: true can_change_status: false As the UPDATER user, send a REST PATCH request that changes the issue status: curl -i -X PATCH 'http://127.0.0.1:8000/api/rest/index.php/issues/<issue_id>' \ -H 'Authorization: <UPDATER_token>' \ -H 'Content-Type: application/json' \ -d '{"status":{"id":50}}' Observe that the request succeeds: HTTP/1.1 200 Issue with id iissue_id Updated Observe that the issue status changed from new / 10 to assigned / 50, even though the UPDATER user does not satisfy $g_update_bug_status_threshold.
Additional Information	Security impact: A user with only UPDATER project access can manipulate issue workflow state through REST without the documented DEVELOPER-level permission required for status changes. This can allow unauthorized movement of issues through the workflow, such as changing issues to acknowledged, assigned, or other workflow states depending on the configured status workflow. CVSS v4.0: CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N Base score: 4.8 Medium CWE: CWE-862: Missing Authorization GitHub username: mamdouhmahfouz
Tags	No tags attached.

dregad 2026-05-25 09:34 developer ~0071169	Thanks for the bug report, I confirm the problem. Advisory https://github.com/mantisbt/mantisbt/security/advisories/GHSA-m7ph-9558-mrx3 created and CVE request sent. Please indicate how you would like to be credited for the finding.

dregad 2026-05-25 09:40 developer ~0071170	PATCH /api/rest/issues was introduced in 2.8.0, see 0023396

mamdo 2026-05-25 09:44 reporter ~0071171	Please credit the finding to Mamdouh Mahfouz and kindly list my GitHub username as mamdouhmahfouz if you do not mind. Thanks for the swift response!

dregad 2026-05-25 11:52 developer ~0071172 Last edited: 2026-05-29 18:31	After further analysis, it appears that the vulnerability is also present in the SOAP API. This is because both APIs rely on the same mc_issue_update() function to update issue, and it is missing quite a few necessary checks compared to regular UI path (bug_update.php). I will implement a quick fix for the g_update_bug_status_threshold, but will defer the workflow check and other corner cases (reporter close, reopen) to the implementation of IssueUpdateCommand, which is too big of a change for a hotfix release. Follow up in 0032861.

dregad 2026-05-29 18:31 developer ~0071185	CVE-2026-49280 assigned

dregad 2026-05-29 19:24 developer ~0071187	@mamdo please review proposed patch https://github.com/mantisbt/mantisbt-ghsa-m7ph-9558-mrx3/pull/1

mamdo 2026-05-30 09:07 reporter ~0071193	The fix looks good to me. I tested both the SOAP and REST APIs, and they no longer allow an UPDATER account to change an issue’s status. One small question: I noticed that the CVE ID no longer appears in the GitHub advisory. Is that expected?

dregad 2026-05-30 09:48 developer ~0071196	Thanks for the feedback. One small question: I noticed that the CVE ID no longer appears in the GitHub advisory. Is that expected? That's strange. Definitely not expected, no idea what happened. I put it back.

dregad 2026-05-30 09:56 developer ~0071197	I merged the fix into a private release branch for now. I will publish this Issue and the Advisory when we're ready to release 2.28.4 (I have other security issues pending).

MantisBT: master-2.28 2d3a5537 2026-05-29 19:18 dregad Details Diff	Check update_bug_status_threshold in mc_issue_update() This missing check was allowing a user having update_bug_threshold to change an Issue's status, even if their access level is below update_bug_status_threshold. Fixes 0037181, GHSA-m7ph-9558-mrx3, CVE-2026-49280		Affected Issues 0037181
	mod - api/soap/mc_issue_api.php		Diff File