VYPR
← All advisories
Moderate severityGHSA Advisory· Published May 11, 2026

MantisBT Vulnerable to Privilege Escalation from Manager to Administrator

CVE-2026-34390

Description

Insufficient access control checks in _ProjectUsersAddCommand_ (used in *manage_proj_user_add.php* and REST API endpoint PUT /project/{id}/users) allows users having *manage_project_threshold* access level (*manager* by default) to grant project-level *administrator* access to any user (including themselves) in any Project they have *manager* rights in.

The normal project-user add form does restrict 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.

Impact

Privilege escalation.

The consequences of the privilege escalation are not as bad as it may sound, because having *administrator* access at Project level is effectively not very different from being *manager*, it does not actually give administrator privileges on the whole MantisBT instance. 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.

### Patches - 69e0180f180ed5acf48a8d281a73683a7bf32461

Workarounds

None

Credits

Thanks to the following security researchers for independently discovering and responsibly reporting the issue: - Dracosec Research Limited (Siu Nam Tang, Chris Chan, Krecendo Hui, William Lam) - Vishal Shukla

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

In MantisBT, a manager can escalate any project user to administrator via forged access_level because backend validation lacks access-level bounds checking

Vulnerability

Overview

CVE-2026-34390 is an insufficient access control vulnerability in MantisBT's ProjectUsersAddCommand handler, which backs both the web form (manage_proj_user_add.php) and the REST API (PUT /project/{id}/users). While the front-end limits selectable roles to the actor's own access level or below, the backend accepts a forged, higher access_level value without re-validating that it does not exceed the actor's current project role [1][4]. This lack of server-side bounds checking allows a user with manage_project_threshold` (default: manager) to grant themselves or any other user project-level administrator access in any project where they already hold manager rights.

Attack

Vector and Prerequisites

The attacker must have manager-level access to at least one project. No special network position is required; the vulnerability can be exploited by submitting a crafted HTTP request (either a POST to manage_proj_user_add.php or a PUT call to the corresponding REST endpoint) containing an access_level parameter higher than the manager's own permitted role [1][3]. The existing code in ProjectUsersAddCommand::validate() only checks that the actor meets the manage_project_threshold and project_user_threshold levels, but never compares the requested role against the actor's own access_level of the actor [3].

Impact

Successful exploitation results in privilege escalation within a project: the targeted user gains project-level administrator rights. However, this does not grant instance-wide administrative capabilities—project administrators cannot delete the project, manage global users, or access system-level settings [4]. The practical difference between manager and project administrator in MantisBT is minimal, but the escalation still represents a violation of the intended role-based access control policy and can be leveraged for lateral movement within the project.

Mitigation

The vendor has patched the issue in commit 69e0180f180ed5acf48a8d281a73683a7bf32461 [1][4]. No workaround is available; users must update to the patched version. The GitHub Security Advisory (GHSA-frf7-jhp9-jxm6) confirms the fix and credits independent researchers for coordinated disclosure [4].

References
  1. 0037002: Privilege Escalation Due to Improper Authorization in Project Role Assignment
  2. 0036995: CVE-2026-34390: Privilege Escalation from Manager to Administrator role per project basis
  3. Privilege Escalation from Manager to Project-level Administrator

AI Insight generated on May 18, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected packages

Versions sourced from the GitHub Security Advisory.

PackageAffected versionsPatched versions
mantisbt/mantisbtPackagist
< 2.28.22.28.2

Affected products

2
  • Mantisbt/MantisbtGHSA2 versions
    <= 2.28.1+ 1 more
    • (no CPE)range: <= 2.28.1
    • (no CPE)

Patches

1
69e0180f180e

Fix privilege escalation in ProjectUsersAddCommand

https://github.com/mantisbt/mantisbtDamien RegadMar 27, 2026via ghsa
commit
1 file changed · +4 −0
  • core/commands/ProjectUsersAddCommand.php+4 −0 modified
    @@ -102,6 +102,10 @@ function validate() {
 		project_ensure_exists( $this->project_id );
 
 		$t_actor_id = auth_get_current_user_id();
+		# Do not allow adding a user with an access level higher than the actor's
+		if( $this->access_level > access_get_project_level( $this->project_id, $t_actor_id ) ) {
+			throw new ClientException( "Access level cannot be higher than your own", ERROR_ACCESS_DENIED );
+		}
 
 		# We should check both since we are in the project section and an
 		# admin might raise the first threshold and not realize they need

Vulnerability mechanics

AI mechanics synthesis has not run for this CVE yet.

References

5

News mentions

0

No linked articles in our index yet.