CVE-2024-29897

Executive Summary

CVE-2024-29897 is an improper access control vulnerability in the CreateWiki extension for MediaWiki, developed by Miraheze. The flaw allows users who possess the delete or suppressrevision user rights on any wiki within the Miraheze farm to view suppressed (deleted/hidden) wiki creation requests. This is achieved by directly accessing the request's entry on Special:RequestWikiQueue on the wiki where the user holds those elevated permissions. The vulnerability also briefly affected the REST API before being quickly patched. The CVSS score is 4.9 (Medium), reflecting the low complexity and network-based attack vector, but limited to confidentiality impact. No public proof-of-concept or exploit code has been released.

Supply Chain & Package Security

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby). It is a custom MediaWiki extension (CreateWiki) used within the Miraheze wiki farm ecosystem. The risk is limited to organizations that self-host a Miraheze-style wiki farm or use the CreateWiki extension directly.

CVSS Breakdown & Threat Level

• CVSS Score: 4.9 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
• Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low (L) – No special conditions or race conditions are required.
• Privileges Required (PR): Low (L) – The attacker must have a valid account with delete or suppressrevision rights on at least one wiki in the farm.
• User Interaction (UI): None (N) – No victim interaction is needed.
• Scope (S): Unchanged (U) – The vulnerable component and the affected component are the same.
• Confidentiality (C): Low (L) – Only suppressed wiki request data is exposed, not full system compromise.
• Integrity (I): None (N) – No data modification is possible.
• Availability (A): None (N) – No denial of service.

Threat Level: Medium. The vulnerability requires authenticated access with specific privileges, but the privileges are relatively common in a wiki farm environment. The impact is limited to reading suppressed requests, which may contain sensitive information.

Deep Dive & Mechanics

The CreateWiki extension manages the lifecycle of wiki creation requests. When a request is suppressed (deleted or hidden), it should be invisible to all users except those with global suppression rights. The vulnerability arises because the access control check on Special:RequestWikiQueue only verifies that the user has delete or suppressrevision rights on the current wiki, not globally. In a wiki farm, a user may have these rights on one wiki (e.g., a test wiki) but not on others. By navigating to Special:RequestWikiQueue on that wiki, they can view suppressed requests from any wiki in the farm.

The REST API vulnerability was similar but was fixed in commit 6bc0685. The main web interface vulnerability was fixed in commit 23415c17ffb4832667c06abcf1eadadefd4c8937.

Root Cause: The SpecialRequestWikiQueue special page and the REST API endpoint did not perform a global permission check. They only checked local wiki permissions, allowing a user with local delete/suppressrevision rights to bypass the intended access control.

Vulnerable vs. Patched Code

The following is a simplified representation of the vulnerable and patched code logic.

Vulnerable Code (Simplified):

// In SpecialRequestWikiQueue.php
function execute( $par ) {
    // ... 
    $user = $this->getUser();
    // Only checks local permissions
    if ( !$user->isAllowed( 'delete' ) && !$user->isAllowed( 'suppressrevision' ) ) {
        throw new PermissionsError( 'delete' );
    }
    // ... display suppressed requests
}

Patched Code (Simplified):

// In SpecialRequestWikiQueue.php
function execute( $par ) {
    // ...
    $user = $this->getUser();
    // Now checks global permissions using a dedicated method
    if ( !$user->isAllowedAny( 'delete', 'suppressrevision' ) || !$this->checkGlobalPermission( $user ) ) {
        throw new PermissionsError( 'delete' );
    }
    // ... display suppressed requests
}

private function checkGlobalPermission( $user ) {
    // Verify that the user has the required rights globally, not just locally
    // This might involve checking against a global group or a farm-wide permission system
    return $user->isAllowedGlobal( 'delete' ) || $user->isAllowedGlobal( 'suppressrevision' );
}

Key Difference: The patched version introduces a checkGlobalPermission method that verifies the user has the required rights across the entire wiki farm, not just on the local wiki.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A valid user account on a Miraheze wiki farm.
• The user must have delete or suppressrevision rights on at least one wiki in the farm (e.g., a test wiki).

Exploitation Steps:

1. Identify a wiki where you have delete or suppressrevision rights. This could be a wiki you created or one where you were granted these rights.
2. Navigate to https://[your-farm-url]/wiki/Special:RequestWikiQueue on that wiki.
3. The page will display all wiki creation requests, including those that have been suppressed (deleted/hidden) on other wikis.
4. View the details of any suppressed request to access its content.

Note: No public exploit code is available. The vulnerability is purely a web interface access control bypass.

Blue Team

Detection:

• Monitor access logs for Special:RequestWikiQueue from users who do not have global delete or suppressrevision rights.
• Alert on any access to Special:RequestWikiQueue from a wiki where the user has local delete/suppressrevision rights but not global rights.

Hunting:

• Query database for any suppressed requests that have been viewed by users without global suppression rights.
• Review user permission assignments to identify users with local delete/suppressrevision rights on multiple wikis.

Indicators of Compromise (IOCs)

• URL Pattern: Access to */wiki/Special:RequestWikiQueue from a user with local but not global delete/suppressrevision rights.
• Log Entry: Successful access to Special:RequestWikiQueue by a user who does not have global delete or suppressrevision rights.
• Database Anomaly: Suppressed requests that have been viewed by unauthorized users (if logging is enabled).

Detection Engineering

YARA Rule

rule CVE_2024_29897_CreateWiki_AccessControl {
    meta:
        description = "Detects access to Special:RequestWikiQueue by users with local delete/suppressrevision rights"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-29897"
        hash = "unknown"
    strings:
        $url_pattern = "Special:RequestWikiQueue"
        $delete_right = "delete"
        $suppress_right = "suppressrevision"
    condition:
        $url_pattern and ($delete_right or $suppress_right)
}

Sigma Rule

title: CVE-2024-29897 - CreateWiki Access Control Bypass
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects access to Special:RequestWikiQueue by users with local delete/suppressrevision rights
author: Valters IT
date: 2024/10/27
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-29897
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-uri-query|contains: "Special:RequestWikiQueue"
    condition: selection
falsepositives:
    - Legitimate global administrators
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-29897 - CreateWiki Access Control Bypass"; flow:to_server,established; content:"Special:RequestWikiQueue"; http_uri; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Patch: Apply the fix by updating the CreateWiki extension to commit 23415c17ffb4832667c06abcf1eadadefd4c8937 or later.
2. Workaround: If patching is not immediately possible, restrict the delete and suppressrevision rights to only trusted global administrators. Remove these rights from local wiki users.

Long-Term Measures:

1. Code Review: Conduct a thorough code review of all special pages and API endpoints in the CreateWiki extension to ensure proper global permission checks.
2. Permission Audit: Regularly audit user permissions across the wiki farm to ensure that sensitive rights are not granted unnecessarily.
3. Monitoring: Implement monitoring for access to Special:RequestWikiQueue and alert on any anomalous access patterns.

Valters IT Signature

This report was generated by Valters IT DevSecOps & CTI Expert System.