Listen to this Post
How the mentioned CVE works
- Vulnerable Component: The
ProjectUsersAddCommand, used by the web form (manage_proj_user_add.php) and the REST API endpoint (PUT /project/{id}/users), lacks sufficient access control checks. - Attack Vector: An authenticated user with the `manage_project_threshold` privilege (the default “manager” role) can exploit this flaw.
- The Flaw: While the user interface restricts the access levels a manager can assign to their own role or lower, the backend command handler does not perform this same validation.
- Exploitation: A malicious manager can intercept the request to add a user to a project and modify the `access_level` parameter, forging it to a value higher than their own (e.g., granting “administrator” access).
- Outcome: The backend handler accepts this forged, higher value without performing an authorization check, directly writing it to the database.
- Privilege Escalation: This allows a project manager to grant themselves or any other user project-level administrator access in any project where they have managerial rights.
- Impact Context: Project-level administrator access in MantisBT is functionally similar to a manager role and does not grant global administrative privileges over the entire MantisBT instance.
dailycve form
Platform: MantisBT
Version: Prior patch
Vulnerability : Insufficient access control
Severity: Moderate
date: 2026-05-09
Prediction: 2026-05-16
What Undercode Say:
Analytics
Find all users with project-level admin access in a MantisDB database mysql -u mantis_user -p -D mantisdb -e "SELECT u.id, u.username, p.name, pu.access_level FROM mantis_user_table u JOIN mantis_project_user_list pu ON u.id = pu.user_id JOIN mantis_project_table p ON pu.project_id = p.id WHERE pu.access_level >= 90;"
Audit project events for suspicious access_level assignments in the logs
grep -E "('access_level'|'ProjectUserAddCommand')" /var/log/mantisbt/events.log | jq '.[] | select(.event == "ProjectUserAddCommand") | {timestamp, user_id, target_user_id, project_id, requested_level}'
Search for the vulnerable endpoint usage in web server access logs grep "PUT /api/rest/projects/[0-9]/users" /var/log/nginx/access.log
Exploit:
Craft a forged `PUT` request to the REST API endpoint to escalate privileges. A project manager can execute this command using curl, replacing the variables with the target project ID and the ID of the user to be upgraded.
curl -X PUT 'https://target-mantisbt.com/api/rest/projects/1/users' \
-H 'Authorization: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{"user_id": 123, "access_level": 90}'
Protection from this CVE
Apply the official patch by updating MantisBT to a version that includes the commit 69e0180f180ed5acf48a8d281a73683a7bf32461. If an immediate update is not possible, implement strict input validation on the `access_level` parameter at the web application firewall (WAF) or network level, though a workaround is not officially provided.
Impact
- Privilege Escalation: A project manager can grant project-level admin access to any user, including themselves.
- Integrity Compromise: The primary impact is on the integrity of the role-based access control (RBAC) system, as assigned roles can be silently overridden. The confidentiality of data is not directly affected, nor is system availability.
- Limited Scope: The escalation is confined to project-level roles and does not compromise the global MantisBT instance.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
