CVE-2026-34390: MantisBT Privilege Escalation Vulnerability

CVE-2026-34390 Overview

CVE-2026-34390 is a privilege escalation vulnerability in Mantis Bug Tracker (MantisBT), an open source issue tracker. Versions 2.28.1 and prior contain insufficient access control checks in the ProjectUsersAddCommand handler exposed through manage_proj_user_add.php. Users holding the manage_project_threshold access level (project manager by default) can grant project-level administrator access to any user, including themselves, within projects they manage. The flaw stems from the backend accepting a forged access_level value despite UI-side restrictions. MantisBT released a fix in version 2.28.2.

Critical Impact

Authenticated project managers can elevate themselves or others to project administrator within projects they already manage, but cannot obtain global MantisBT instance administrator privileges.

Affected Products

• Mantis Bug Tracker (MantisBT) versions 2.28.1 and prior
• MantisBT manage_proj_user_add.php endpoint
• MantisBT ProjectUsersAddCommand backend handler

Discovery Timeline

• 2026-05-19 - CVE-2026-34390 published to NVD
• 2026-05-20 - Last updated in NVD database

Technical Details for CVE-2026-34390

Vulnerability Analysis

The vulnerability is a Broken Access Control issue classified under [CWE-284]. MantisBT's ProjectUsersAddCommand, invoked through manage_proj_user_add.php, manages user-to-project assignments and the access level granted within each project. The frontend project-user add form restricts selectable access levels to the actor's own project role or below. The backend handler, however, does not re-validate the submitted access_level against the requestor's role. An attacker who already holds manage_project_threshold rights can submit a crafted request with an arbitrarily high access_level value, and the handler writes it to the database without rejection.

Root Cause

The root cause is a server-side authorization check that trusts client-supplied data. The form correctly enforces the ceiling on access levels in HTML, but ProjectUsersAddCommand lacks a corresponding server-side check that compares the requested access_level against the caller's effective role within the target project. This violates the principle of complete mediation and falls within the CWE-284 Improper Access Control category.

Attack Vector

Exploitation requires an authenticated account that already holds manager-equivalent privileges in at least one project. The attacker sends a forged HTTP request to manage_proj_user_add.php with an elevated access_level parameter (for example, the integer value corresponding to project administrator). The backend persists the assignment, granting project administrator status to the chosen user. The escalation is bounded by the project scope. The promoted account cannot delete the project itself and gains no access to global functions such as user management, plugin configuration, custom fields, or instance-wide administration.

No verified public proof-of-concept code is available. Technical details are documented in the GitHub Security Advisory GHSA-frf7-jhp9-jxm6 and the upstream MantisBT Bug Report #36995.

Detection Methods for CVE-2026-34390

Indicators of Compromise

• Entries in the MantisBT mantis_project_user_list_table showing access levels above the granting user's role at the time of assignment.
• HTTP POST requests to manage_proj_user_add.php containing an access_level parameter higher than the requester's project role.
• MantisBT audit log entries showing project administrator assignments performed by accounts that previously held only manager-level rights.

Detection Strategies

• Compare current access_level values in the project user table against historical role assignments and flag upward changes not authorized by an instance administrator.
• Inspect web server access logs for POST requests to manage_proj_user_add.php and correlate the submitting user's role with the resulting access level grant.
• Review MantisBT history and audit trails for unexpected promotions to project administrator scoped to a single project.

Monitoring Recommendations

• Forward MantisBT application logs and web server logs to a centralized analytics platform for query against suspicious privilege change patterns.
• Alert on any new project administrator assignment that is not performed by a global site administrator account.
• Periodically export and review project user assignments to identify drift from approved role baselines.

How to Mitigate CVE-2026-34390

Immediate Actions Required

• Upgrade MantisBT to version 2.28.2 or later, which contains the patched ProjectUsersAddCommand access control check.
• Audit all project administrator assignments made on MantisBT instances running 2.28.1 or earlier and revert unauthorized escalations.
• Restrict the assignment of the manager role to trusted personnel until upgrade is complete.

Patch Information

The issue is fixed in MantisBT 2.28.2. The upstream patch is available in the GitHub commit 69e0180f, which adds server-side validation in ProjectUsersAddCommand to ensure the submitted access_level does not exceed the requesting user's role within the target project. Additional context is available in the GitHub Security Advisory and MantisBT Bug Report #37002.

Workarounds

• Reduce the number of accounts holding the manage_project_threshold access level until the upgrade is applied.
• Place MantisBT behind a reverse proxy or web application firewall and block POST requests to manage_proj_user_add.php containing access_level values above the manager threshold.
• Implement scheduled reviews of project user lists to detect and revert unauthorized administrator grants.

# Upgrade MantisBT to the patched release
cd /var/www/mantisbt
php admin/check_install.php
# Download and deploy MantisBT 2.28.2, then run the upgrade script
php admin/install.php