CVE-2026-34970: MantisBT Information Disclosure Flaw

CVE-2026-34970 Overview

CVE-2026-34970 is an information disclosure vulnerability in Mantis Bug Tracker (MantisBT), an open source issue tracking application. The flaw affects all versions up to and including 2.28.1. A bugnote author retains access to the note's Revisions page after losing access to the parent private issue. This allows the author to continue viewing revision history that should be restricted along with the parent bug. The vulnerability is classified as [CWE-200] Exposure of Sensitive Information to an Unauthorized Actor. Maintainers fixed the issue in version 2.28.2.

Critical Impact

An authenticated bugnote author can read bugnote revision history of a private issue they no longer have authorization to view, exposing potentially sensitive project information.

Affected Products

• Mantis Bug Tracker (MantisBT) versions 2.28.1 and prior
• MantisBT installations exposing bugnote revisions functionality
• MantisBT deployments using private issue access controls

Discovery Timeline

• 2026-05-20 - CVE-2026-34970 published to NVD
• 2026-05-20 - Last updated in NVD database

Technical Details for CVE-2026-34970

Vulnerability Analysis

The vulnerability resides in the bugnote revision access control logic of MantisBT. When a user authors a bugnote on an issue, the application grants persistent access to that note's Revisions page based on authorship. The access check does not re-evaluate whether the user still has permission to view the parent bug.

If an administrator later restricts the parent issue, makes it private, or removes the user from the project, the user's view access to the bug itself is revoked. However, the Revisions page for any bugnote they authored remains reachable. This produces a confused-deputy condition where note-level authorship overrides bug-level authorization.

The impact is limited to confidentiality. An attacker cannot modify data or affect availability through this flaw. The disclosed content is restricted to the bugnote revision history rather than the full bug record.

Root Cause

The root cause is an incomplete authorization check in core/access_api.php. The function controlling access to bugnote revisions verified only the bugnote revision threshold or bugnote reporter identity. It did not verify that the requesting user still had access to the parent bug.

Attack Vector

Exploitation requires an authenticated account that previously authored a bugnote on a now-restricted issue. The attacker navigates directly to the bugnote Revisions URL. The application returns the revision content without re-validating parent bug access. No special tooling or elevated privileges are required.

 /**
  * Return true if user is allowed to view bugnote revisions.
  *
- * User must have $g_bug_revision_view_threshold or be the bugnote's reporter.
+ * User must have $g_bug_revision_view_threshold or be the bugnote's reporter,
+ * and have access to the parent bug.
  *
  * @param int $p_bugnote_id
  * @param int $p_user_id

Source: GitHub Commit 71df1f6

Detection Methods for CVE-2026-34970

Indicators of Compromise

• HTTP requests to bugnote_revision_view_page.php or similar revision endpoints by users whose access to the parent bug has been revoked
• Web access logs showing successful (HTTP 200) responses to revision page requests for issues marked private
• Audit log entries indicating bugnote revision views without corresponding parent bug view events

Detection Strategies

• Correlate MantisBT access logs against the project membership table to identify revision page views by users no longer assigned to the relevant project
• Review database query patterns for mantis_bugnote_revision_table reads originating from sessions that lack bug view permission
• Inspect the MantisBT version banner across deployments and flag instances reporting 2.28.1 or earlier

Monitoring Recommendations

• Enable verbose access logging on the MantisBT web server and forward events to a centralized log platform for correlation
• Alert on access to revision URLs containing bugnote_id parameters by accounts recently removed from a project
• Track all access attempts to private issues and their associated bugnotes during the 30 days following privacy changes

How to Mitigate CVE-2026-34970

Immediate Actions Required

• Upgrade MantisBT to version 2.28.2 or later, which contains commit 71df1f6 adding the parent bug access check
• Audit recent revision page access for bugnotes attached to issues that were made private or restricted
• Review project membership changes and confirm no former members retain access to restricted bug data

Patch Information

The fix is delivered in MantisBT 2.28.2. The patch modifies access_has_bugnote_revision_level() in core/access_api.php to require that the requesting user have access to the parent bug in addition to either meeting $g_bug_revision_view_threshold or being the bugnote's reporter. Details are available in the MantisBT Security Advisory GHSA-crmx-4p49-46m2 and MantisBT Bug 36978.

Workarounds

• Restrict the global $g_bug_revision_view_threshold configuration value to a high role such as MANAGER or ADMINISTRATOR to limit who can view any revisions
• Disable bugnote revisions tracking entirely by setting $g_bug_revisions_view_threshold above the highest assigned role if revision history is not operationally required
• Use a reverse proxy or web application firewall rule to block direct requests to bugnote revision endpoints from non-administrative users until patched

# Configuration example - config_inc.php hardening
$g_bug_revision_view_threshold = MANAGER;
$g_bug_revision_drop_threshold = ADMINISTRATOR;