MantisBT CVE-2026-34390

Exploitation requires an authenticated session with at least manage_project_threshold access (manager role by default) on the target MantisBT project - this is a non-trivial prerequisite. The attack targets the REST API endpoint PUT /project/{id}/users or the web form manage_proj_user_add.php by submitting a forged access_level parameter value exceeding the actor's own project role. No special non-default configuration is required; any default MantisBT deployment with at least one project manager user is affected on versions <= 2.28.1. Exploitation is limited to projects the attacking account already manages - a manager cannot escalate privileges on projects where they have no existing role. The elevated result is project-level administrator only, which does not unlock instance-wide administrative functions (user management, plugin management, custom fields, etc.).

The CVSS 4.0 score of 5.1 (AV:N/AC:L/AT:N/PR:H/UI:N) accurately reflects the constrained impact: exploitation requires prior authentication as a project manager, and the resulting privilege gain is scoped to project-level administrator - a role the advisory explicitly notes is 'not very different from manager' in terms of actual capability. EPSS at 0.04% (11th percentile) confirms very low opportunistic exploitation probability, consistent with the high-privilege prerequisite. SSVC flags the issue as automatable with a POC, which is notable: a malicious manager could script bulk privilege escalations across all projects they manage without manual steps. The vulnerability is not listed in CISA KEV, indicating no confirmed active exploitation in the wild. The combination of PR:H and limited real-world impact delta (manager vs. project-admin) makes this a medium-low priority for most organizations, though environments with strict project-level RBAC boundaries should treat it as higher priority.

An authenticated MantisBT project manager intercepts or crafts a PUT /project/{id}/users REST API request and replaces the access_level field with the project-administrator value, bypassing the UI-enforced restriction. The backend accepts and writes the elevated role without validation, promoting the actor or a chosen accomplice to project administrator on any project the attacker manages. A proof-of-concept for this technique exists per SSVC data, making the attack repeatable and scriptable.