CVE-2024-34080

Executive Summary

CVE-2024-34080 is an information disclosure vulnerability in MantisBT, an open-source issue tracker. The flaw allows an attacker to infer the existence of notes, the author's name, the creation timestamp, and the associated issue ID from a different issue that the user does not have permission to view. This is achieved through hyperlinks that are generated even when the user lacks access to the target note. The vulnerability has a CVSS score of 5.3 (Medium) and affects versions prior to 2.26.2. No public exploit code or proof-of-concept is currently available, and the EPSS score is 0.0%, indicating a low likelihood of exploitation in the wild.

Supply Chain & Package Security

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby) but is a direct issue in the MantisBT application source code. The fix is applied by upgrading the application itself.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
• Base Score: 5.3 (Medium)
• Attack Vector: Network (AV:N) – The vulnerability can be exploited remotely.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: None (PR:N) – No authentication is needed to trigger the disclosure.
• User Interaction: Required (UI:R) – The victim must click on a crafted link.
• Scope: Unchanged (S:U) – The vulnerability does not affect other components.
• Confidentiality Impact: Low (C:L) – Limited information is disclosed (note existence, author, timestamp, issue ID).
• Integrity Impact: None (I:N) – No data modification is possible.
• Availability Impact: None (A:N) – No denial of service.

Threat Level: Medium. The vulnerability requires user interaction and only leaks metadata, not the actual note content. However, it can be used for reconnaissance to map relationships between issues and users.

Deep Dive & Mechanics

The vulnerability resides in the note referencing functionality of MantisBT. When an issue (Issue A) contains a reference to a note from another issue (Issue B), the system generates a hyperlink to that note. The hyperlink is created even if the current user does not have access to Issue B. The link itself, its label, and its tooltip reveal the following information:

• The existence of the note.
• The note author's name.
• The note creation timestamp.
• The issue ID to which the note belongs.

The core issue is that the access control check is performed only when the user clicks the link (resulting in an "Access Denied" error), but the metadata is already exposed in the UI before the click. This is a classic case of information disclosure via improper access control on UI elements.

The vulnerable code likely constructs the note link without first verifying the user's permissions to the target issue. The patch in version 2.26.2 ensures that the link is only rendered if the user has the necessary permissions.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

// In a view or helper function
$note_link = "<a href='view.php?id=" . $note->bug_id . "#note_" . $note->id . "'>" . $note->author . " - " . $note->date_submitted . "</a>";
// No permission check before generating the link

Patched Code (Conceptual):

// In a view or helper function
if ( access_has_bug_level( config_get( 'view_private_bugnote_threshold' ), $note->bug_id ) ) {
    $note_link = "<a href='view.php?id=" . $note->bug_id . "#note_" . $note->id . "'>" . $note->author . " - " . $note->date_submitted . "</a>";
} else {
    $note_link = "Note hidden";
}
// Permission check prevents link generation for unauthorized users

The patch adds a permission check before rendering the hyperlink, ensuring that users without access to the target issue do not see any metadata.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A MantisBT instance running version < 2.26.2.
• Two issues: Issue A (accessible to the attacker) and Issue B (private, with a note).
• The attacker must know or guess the ID of Issue B.

Steps:

1. Create or find an issue (Issue A) that you can edit.
2. Add a note to Issue A that references a note from Issue B. The reference format is typically note:<note_id> or a direct link like view.php?id=<issue_B_id>#note_<note_id>.
3. View Issue A. The hyperlink to the note from Issue B will be displayed, showing the author name, timestamp, and issue ID.
4. Clicking the link will result in an "Access Denied" error, but the metadata has already been disclosed.

Example Attack:

• Attacker creates Issue A with ID 100.
• Attacker adds a note: "See note: view.php?id=50#note_123"
• When viewing Issue A, the link shows "John Doe - 2024-01-15 10:30:00" (author and timestamp) and the link points to issue ID 50.
• The attacker now knows that issue 50 exists, has a note by John Doe created on that date.

Blue Team (Defense & Detection)

Detection:

• Monitor for unusual patterns in note references, especially references to issues that the referencing user should not have access to.
• Log all access to issue pages and note links, and alert on repeated "Access Denied" errors for note links.

Prevention:

• Apply the patch by upgrading to MantisBT 2.26.2 or later.
• Implement strict access control checks on all UI elements that display issue or note metadata.
• Consider disabling note referencing for users with limited permissions.

Indicators of Compromise (IOCs)

• Network: HTTP requests to view.php?id=<issue_id>#note_<note_id> where the user does not have access to the target issue.
• Logs: Repeated "Access Denied" errors for note links in the application logs.
• File: No specific file IOCs; the vulnerability is logic-based.

Detection Engineering

YARA Rule

rule CVE_2024_34080_MantisBT_InfoDisclosure {
    meta:
        description = "Detects potential exploitation of CVE-2024-34080 in MantisBT logs"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-34080"
    strings:
        $access_denied = "Access Denied" nocase
        $note_link = "view.php?id=" nocase
        $note_ref = "#note_" nocase
    condition:
        all of them
}

Sigma Rule

title: CVE-2024-34080 MantisBT Note Information Disclosure
id: 12345678-1234-1234-1234-123456789abc
status: experimental
description: Detects attempts to exploit CVE-2024-34080 by accessing note links without proper permissions.
author: Valters IT
date: 2024-10-27
logsource:
    category: application
    product: mantisbt
detection:
    selection:
        EventID: 2001  # Example: Access Denied event
        Message|contains: 'Access Denied'
        Message|contains: 'view.php?id='
        Message|contains: '#note_'
    condition: selection
falsepositives:
    - Legitimate users clicking on links they should not have access to (rare)
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-34080 MantisBT Note Information Disclosure Attempt"; flow:to_server,established; content:"view.php?id="; http_uri; content:"#note_"; http_uri; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

• Upgrade MantisBT to version 2.26.2 or later. This is the only known fix.
• If upgrade is not possible, consider disabling the note referencing feature by modifying the application code to remove the hyperlink generation for unauthorized users.

Long-term:

• Implement a security review process for all UI elements that display cross-issue references.
• Enforce the principle of least privilege for all user roles.
• Regularly update MantisBT to the latest version.

Workarounds:

• No official workarounds are available. The only mitigation is to apply the patch.

Valters IT