MantisBT CVE-2026-34390
MEDIUMSeverity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-accessible via REST API; PR:H because manager-level project authentication is required; S:U and limited C:L/I:L since impact is bounded to project-scope role modification only.
Primary rating from Vendor (https://github.com/mantisbt/mantisbt).
CVSS VectorVendor: https://github.com/mantisbt/mantisbt
Lifecycle Timeline
4DescriptionCVE.org
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
AnalysisAI
Privilege escalation in MantisBT allows authenticated project managers to grant project-level administrator access to any user - including themselves - by submitting a forged access_level value to the ProjectUsersAddCommand handler via manage_proj_user_add.php or the REST API endpoint PUT /project/{id}/users. The frontend form correctly restricts selectable access levels to the actor's own role or below, but the backend command (versions <= 2.28.1) performs no equivalent server-side enforcement, accepting and persisting the elevated value. A proof-of-concept exists per SSVC data; however, real-world impact is bounded to project-scoped privilege elevation and does not confer instance-wide administrative capabilities such as managing users, plugins, or custom fields globally.
Technical ContextAI
MantisBT is a PHP-based open-source bug-tracking system distributed via Composer (pkg:composer/mantisbt/mantisbt). The flaw is rooted in CWE-284 (Improper Access Control): the ProjectUsersAddCommand class, shared between the web form handler manage_proj_user_add.php and the REST API, trusted the client-supplied access_level field without comparing it against the authenticated actor's own project role. The commit diff (69e0180f) shows the fix adds a single server-side guard - access_get_project_level() compared against the submitted value - confirming that the validation gap was entirely absent in the pre-patch code. The REST API surface (PUT /project/{id}/users) makes the attack scriptable and repeatable without any UI interaction.
RemediationAI
Upgrade MantisBT to version 2.28.2, which contains the server-side access_level validation added in commit 69e0180f180ed5acf48a8d281a73683a7bf32461 (https://github.com/mantisbt/mantisbt/commit/69e0180f180ed5acf48a8d281a73683a7bf32461). The vendor advisory explicitly lists no workarounds. If immediate upgrade is not possible, organizations can reduce risk by auditing the project manager role assignments and restricting which users hold manage_project_threshold access, thereby limiting the pool of accounts that could exploit this path. Additionally, network-level restrictions on the REST API endpoint PUT /project/{id}/users (e.g., WAF rules blocking unexpected access_level values) may reduce automated exploitation risk, though this is not a complete mitigation. The full advisory is at https://github.com/mantisbt/mantisbt/security/advisories/GHSA-frf7-jhp9-jxm6.
In PHP versions 7.1.x below 7.1.33, 7.2.x below 7.2.24 and 7.3.x below 7.3.11 in certain configurations of FPM setup it
sapi/cgi/cgi_main.c in PHP before 5.3.12 and 5.4.x before 5.4.2, when configured as a CGI script (aka php-cgi), does not
(1) boardData102.php, (2) boardData103.php, (3) boardDataJP.php, (4) boardDataNA.php, and (5) boardDataWW.php in Netgear
The '/common/download_agent_installer.php' script in the Quest KACE System Management Appliance 8.0.318 is accessible by
ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability. Rated critical severity (C
Roundcube Webmail contains a critical PHP object deserialization vulnerability (CVE-2025-49113, CVSS 9.9) that allows au
Util/PHP/eval-stdin.php in PHPUnit before 4.8.28 and 5.x before 5.6.3 allows remote attackers to execute arbitrary PHP c
Palo Alto Networks PAN-OS management web interface contains an authentication bypass allowing unauthenticated attackers
Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re
Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re
The get_referers function in /opt/ws/bin/sblistpack in Sophos Web Appliance before 3.7.9.1 and 3.8 before 3.8.1.1 allows
The Backup Migration plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1
Same weakness CWE-284 – Improper Access Control
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-frf7-jhp9-jxm6