{"answers":{"affected":"2 open source packages ship an affected version, including mantisbt/mantisbt.","exploited":"It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-34390 exists.","fix":"Upgrade mantisbt/mantisbt to 2.28.2 or later.","what":"CVE-2026-34390 is a medium-severity vulnerability in mantisbt, published on 19 May 2026. An attacker needs administrator access to exploit it, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-34390 and fix it if it is affected.\n\nWhat it is: CVE-2026-34390 is a medium-severity vulnerability in mantisbt, published on 19 May 2026. An attacker needs administrator access to exploit it, with no action from the victim.\nExploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-34390 exists.\n\nAffected packages and fixed versions:\n- mantisbt/mantisbt (Packagist): affected all versions; fixed in 2.28.2\n- mantisbt/mantisbt (Packagist): affected all versions; fixed in 2.28.2\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-34390/ (Markdown: https://insights.sbomify.com/CVE-2026-34390/index.md)","id":"CVE-2026-34390","markdown":"https://insights.sbomify.com/CVE-2026-34390/index.md","name":"CVE-2026-34390","record":{"aliases":["GHSA-frf7-jhp9-jxm6"],"analysis":{"component_type":"web_application","fix_type":"upgrade","impacts":["privilege_escalation"],"network_reachable":"yes","non_default_config":false,"product_category":"MantisBT issue tracker","requires_auth":"high_privilege","summary":"MantisBT allows managers to escalate to project-level administrators via forged access levels, requiring an upgrade to fix.","user_interaction":"not_required","vuln_class":"privilege_escalation"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"GitHub_M","cpe":[],"cvss":{"score":5.1,"severity":"medium","source":"cna","vector":"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","version":"4.0"},"cwes":[{"id":"CWE-284","name":"Improper Access Control"}],"description":"Mantis Bug Tracker (MantisBT) is an open source issue tracker. Versions 2.28.1 and prior have a Privilege Escalation vulnerability where insufficient access control checks in ProjectUsersAddCommand (manage_proj_user_add.php) allow 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 restricts 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. The consequences of the privilege escalation are slight, as having administrator access at Project level is effectively not very different from being manager, and 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. This issue has been fixed in version 2.28.2.","ecosystems":["Packagist"],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"weaponised"},"has_fix":true,"headline":"MantisBT: Privilege Escalation from Manager to Administrator","id":"CVE-2026-34390","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":"Packagist","product":null,"products":[],"type":"privilege_escalation","year":"2026"},"n_packages":2,"n_references":4,"next":{"headline":"Fleet Vulnerable to Windows MDM cross-device command disclosure","id":"CVE-2026-34391"},"packages":[{"ecosystem":"Packagist","fixed":["2.28.2"],"introduced":["0"],"last_affected":[],"package":"mantisbt/mantisbt","purl":null,"source":"GHSA-frf7-jhp9-jxm6"},{"ecosystem":"Packagist","fixed":["2.28.2"],"introduced":["0"],"last_affected":[],"package":"mantisbt/mantisbt","purl":"pkg:composer/mantisbt/mantisbt","source":"GHSA-frf7-jhp9-jxm6"}],"prev":{"headline":"Fleet's user account creation via invite does not enforce invited email address","id":"CVE-2026-34389"},"products":["mantisbt"],"published":"2026-05-19","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"yes","exploitation":"poc","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-05-20","vendors":["mantisbt"]},"summary":"MantisBT allows managers to escalate to project-level administrators via forged access levels, requiring an upgrade to fix.","url":"https://insights.sbomify.com/CVE-2026-34390/"}