GHSA-frf7-jhp9-jxm6 — mantisbt/mantisbt
Fix: mantisbt/mantisbt@69e0180GHSA-frf7-jhp9-jxm6 is a CWE-284 vulnerability in mantisbt/mantisbt. A fix is available for mantisbt/mantisbt — see the affected versions and patch details below.
MantisBT Vulnerable to Privilege Escalation from Manager to Administrator
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-frf7-jhp9-jxm6.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
mantisbt/mantisbtReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | mantisbt/mantisbt | all versions | 2.28.2composer require mantisbt/mantisbt:^2.28.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for mantisbt/mantisbt, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update mantisbt/mantisbt to 2.28.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-frf7-jhp9-jxm6 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-frf7-jhp9-jxm6 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-frf7-jhp9-jxm6. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-frf7-jhp9-jxm6 in your dependencies?
O3 Security finds GHSA-frf7-jhp9-jxm6 across Packagist dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.