View Issue Details

IDProjectCategoryView StatusLast Update
0036995mantisbtsecuritypublic2026-05-09 19:56
Reporterdracosectech Assigned Todregad  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Target Version2.28.2Fixed in Version2.28.2 
Summary0036995: CVE-2026-34390: Privilege Escalation from Manager to Administrator role per project basis
Description

Any users with access level "Manager" can grant any users to access level "Administrator" in any projects they have Manager access to, due to missing validation for the user provided input access_level. This allows an attacker with access level "Manager" to escalate the access level to "Administrator", and perform "Administrator" only actions in different projects.

Affected endpoints are:

  1. PUT /api/rest/projects/<project_id>/users/
  2. POST /manage_proj_user_add.php

=========================================================
In the front-end, manager users are not supposed to be able to grant any users to access level "Administrator". Therefore, it is assumed that manager users should only grant users access level up to "Manager": @see attachment (Pasted image 20260323153001.png)

In the back-end, although method validate in class ProjectUsersAddCommand did validate current user's access level must be greater than manage_project_threshold and project_user_threshold (70), it did not validate the user-controlled access_level value also need to be less than current user's access level.

Vulnerable Code Fragment:
mantisbt/core/commands/ProjectUsersAddCommand.php line 99 - 120:

class ProjectUsersAddCommand extends Command {
    // [...]
    function validate() {
        // [...]
        $this->access_level = access_parse_array( $t_access_level );
        // [...]
        $t_actor_id = auth_get_current_user_id();
        // [...]
        $t_access_check = access_has_project_level(
            config_get( 'manage_project_threshold', /* default */ null, $t_actor_id, $this->project_id ),
            $this->project_id );

        $t_access_check = $t_access_check &&
            access_has_project_level(
                config_get( 'project_user_threshold', /* default */ null, $t_actor_id, $this->project_id ),
                $this->project_id );

        if( !$t_access_check ) {
            throw new ClientException( "Access Denied", ERROR_ACCESS_DENIED );
        }
    }
}

Patch

We can patch this vulnerability by validating the user-controlled access_level value to be less than current user's access level in below mantisbt/core/commands/ProjectUsersAddCommand.php line 104:

        $t_actor_id = auth_get_current_user_id(); // line 104
        $t_actor_access_level = access_get_global_level( $t_actor_id );
        if ( $t_actor_access_level < $this->access_level ) {
            throw new ClientException( "Access level cannot be higher than your own access level", ERROR_ACCESS_DENIED );
        }
Steps To Reproduce

To reproduce this vulnerability, we can:

  1. Login as an user with access level "Manager".
  2. Send the following API REST PUT request:
    ** update the 1) <project_id> in URL and 2) <user_name> in the JSON body:
PUT /api/rest/projects/<project_id>/users/ HTTP/1.1
Host: <..OMITTED..>
Cookie: PHPSESSID=<..OMITTED..>; MANTIS_STRING_COOKIE=<..OMITTED..>
Content-Type: application/json
Content-Length: 67

{"user":{"name":"<user_name>"},"access_level":{"name":"administrator"}}

Where the <project_id> in URL is the project ID that you want to update (i.e.: 1), JSON field user.name is the username that you want to escalate its privilege in the project level, and access_level.name is the access level name, such as administrator.

  1. Confirm the access level has been changed by visiting /manage_proj_edit_page.php?project_id=<project_id> in section "Manage Accounts".
Additional Information

Credits: Dracosec Research Limited - Siunam Tang (siunamtang@dracosec.tech), Chris Chan (chrischan@dracosec.tech), Krecendo Hui (krecendohui@dracosec.tech), and William Lam (williamlam@dracosec.tech)

TagsNo tags attached.
Attached Files
Pasted image 20260323153001.png (31,033 bytes)   
Pasted image 20260323153001.png (31,033 bytes)   

Relationships

related to 0032466 closedvboctor REST API: Create Project User 
has duplicate 0037002 closeddregad Privilege Escalation Due to Improper Authorization in Project Role Assignment 

Activities

dregad

dregad

2026-03-26 14:05

developer   ~0070906

Hello,

Thanks for the comprehensive bug report, I confirm the vulnerability, both from GUI and API.

Next steps: I will open an Advisory on GitHub, request a CVE, and test your proposed patch.

For credits, please let me know if I should also mention your company, or just the individual names ?

dracosectech

dracosectech

2026-03-26 23:21

reporter   ~0070907

Hi Dregad,

Thank you for the update and for confirming the vulnerability.
Regarding the credits for the CVE and Advisory, we would like to be listed using both our company name and the individual staff members involved.
Please use the following format:
Dracosec Research Limited (Siu Nam Tang, Chris Chan, Krecendo Hui, William Lam)
Please let us know if you need any further information from our side during the patching or advisory process.

dregad

dregad

2026-03-27 13:40

developer   ~0070908

Last edited: 2026-03-27 13:40

After in-depth analysis, it appears that the vulnerability exists since the original implementation of this feature, over 20 years ago.

It was introduced in the REST API with the ProjectUsersAdd Command, via commit MantisBT master 9ee5e17d in MantisBT 2.26.0, which added the ability to manage Project users (see 0032466).

It's worth mentioning that the vulnerability is effectively not as bad as it may sound, because having escalated administrator privilege at Project level is effectively not very different from being manager - in particular it does not let the upgraded user delete the Project or grant them any access to global administrative functions such as managing Users, Projects, Plugins, Custom Fields, etc.

I created Advisory https://github.com/mantisbt/mantisbt/security/advisories/GHSA-frf7-jhp9-jxm6, and requested assignment of a CVE ID.

Thanks for proposing a patch. However, please note that it does not cover all cases, due to use of access_get_global_level() function, instead of the more restrictive access_get_project_level() which should be used in this context.

dregad

dregad

2026-03-27 15:04

developer   ~0070909

CVE-2026-34390 assigned.

Related Changesets

MantisBT: master-2.28 69e0180f

2026-03-27 13:53

dregad


Details Diff
Fix privilege escalation in ProjectUsersAddCommand

Prevents MANAGER users from upgrading themselves or other users to
project-level ADMINISTRATOR.

Fixes 0036995
Affected Issues
0036995
mod - core/commands/ProjectUsersAddCommand.php Diff File

MantisBT: master-2.28 b1c3430b

2026-05-08 04:05

dregad


Details Diff
Revert "Cannot grant an access level higher than one's own"

This reverts commit 86accbca671a6a2bfe2204e58739b58d4f06b63d.

The vulnerability, identified in Issue 0037002, had in fact already been
reported (and fixed) in Issue 0036995, see commit
69e0180f180ed5acf48a8d281a73683a7bf32461.
Affected Issues
0036995, 0037002
mod - core/commands/ProjectUsersAddCommand.php Diff File