View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0037002 | mantisbt | security | public | 2026-04-01 11:28 | 2026-05-10 07:56 |
| Reporter | ninjasec | Assigned To | dregad | ||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 2.28.1 | ||||
| Summary | 0037002: Privilege Escalation Due to Improper Authorization in Project Role Assignment | ||||
| Description | The normal project-user add form restricts the selectable access levels to the actor's own project role or below. However, the backend handler still accepts a forged higher access_level value and writes it. As a result, a project manager can add another user to the project with a higher role than the manager is allowed to grant. This is a server-side authorization flaw. The UI attempts to enforce the intended policy, but the backend does not apply the same restriction. Affected Code
Why?manage_proj_user_add.php forwards the submitted access level directly into core/commands/ProjectUsersAddCommand.php. ProjectUsersAddCommand::validate() verifies that the actor may manage project users for the project, but it does not enforce that the requested access level is less than or equal to the actor's own project access level. The sibling bulk-update web handler manage_proj_user_update.php does implement this check: if( $t_value > $t_current_user_access_level ) { continue; } This confirms the intended policy and highlights the inconsistency in the add-user path. Preconditions
| ||||
| Steps To Reproduce |
The normal form only offered access levels up to manager:
A forged request was then submitted with access_level=90:
Observed response:
Membership before the request: 2|1|70 Membership after the request: 2|1|70 or curl requests: | ||||
| Additional Information | | ||||
| Tags | No tags attached. | ||||
|
Confirmed. The user can even update their own access level. By default, the minimum access level is manager, not developer (I updated the steps to reproduce accordingly). It's worth noting that an administrator access level on a project does not actually give administrator privileges on the whole MantisBT instance; it is effectively not very different from manager. Advisory https://github.com/mantisbt/mantisbt/security/advisories/GHSA-7xhr-fg7m-j7c7 created and CVE request sent. |
|
|
Proposed patch https://github.com/mantisbt/mantisbt-private/pull/3 |
|
|
CVE-2026-42029 assigned |
|
|
It turns out that this vulnerability had already been reported by @dracosectech in 0036995, so I'm closing this Issue as duplicate. CVE-2026-42029 will be marked as invalid; @ninjasec you will be credited as co-finder on CVE-2026-34390. |
|
|
MantisBT: master-2.28 86accbca 2026-04-19 11:01 Details Diff |
Cannot grant an access level higher than one's own When adding a user to a project, the ProjectUsersAddCommand failed to check that the target access level was lower or equal to the user's own, allowing privilege escalation. Fixes 0037002, GHSA-7xhr-fg7m-j7c7 Co-authored-by: Vishal Shukla <shukla304@gmail.com> |
Affected Issues 0037002 |
|
| mod - core/commands/ProjectUsersAddCommand.php | Diff File | ||
|
MantisBT: master-2.28 b1c3430b 2026-05-08 04:05 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 | ||