CVE-2024-34701

Executive Summary

CVE-2024-34701 is an improper access control vulnerability in the CreateWiki extension for MediaWiki, used by Miraheze for wiki farm management. The flaw allows an authenticated user to impersonate the requester of a wiki creation request if their local user ID on any wiki in the farm matches the requester’s local ID on the originating wiki. This enables unauthorized actions on Special:RequestWikiQueue, such as approving, rejecting, or modifying requests. The CVSS score is 5.9 (Medium), with low attack complexity and no user interaction required beyond authentication. No public exploit code or proof-of-concept is available, but the vulnerability is logically exploitable in multi-wiki environments. The patch restricts access to the REST API and special pages to only the global wiki, preventing cross-wiki impersonation.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – exploitable remotely.
• Attack Complexity (AC): Low (L) – no special conditions required.
• Privileges Required (PR): Low (L) – attacker needs a valid account on any wiki in the farm.
• User Interaction (UI): None (N) – no victim action needed.
• Scope (S): Unchanged (U) – impact stays within the same security authority.
• Confidentiality (C): Low (L) – limited information disclosure (request details).
• Integrity (I): Low (L) – unauthorized modification of request status.
• Availability (A): None (N) – no denial of service.

Threat Level: Medium. The vulnerability requires authentication but allows lateral privilege escalation within the wiki farm. It is particularly dangerous in large farms where user IDs may collide across wikis.

Deep Dive & Mechanics

The CreateWiki extension manages wiki creation requests via Special:RequestWikiQueue. Each request is associated with a user ID on the wiki where the request was made. The vulnerability arises because the extension does not validate that the user accessing a request is the same user across the entire farm. Instead, it only checks if the local user ID on the current wiki matches the requester’s local ID on the originating wiki.

Attack Flow:

1. Attacker registers an account on any wiki in the farm (Wiki B) and obtains a local user ID (e.g., 123).
2. On a different wiki (Wiki A), a legitimate user with local ID 123 submits a wiki creation request.
3. Attacker navigates to Special:RequestWikiQueue on Wiki B.
4. Because the attacker’s local ID on Wiki B matches the requester’s local ID on Wiki A, the extension treats the attacker as the requester.
5. Attacker can then approve, reject, or modify the request, potentially creating unauthorized wikis or blocking legitimate ones.

Root Cause: The extension uses $wgUser->getId() without cross-wiki normalization. In a wiki farm, user IDs are local to each wiki and can collide. The fix introduces a global wiki concept ($wgCreateWikiGlobalWiki) and restricts all sensitive operations to that wiki only.

Vulnerable vs. Patched Code

Vulnerable Code (simplified):

// In SpecialRequestWikiQueue.php
$requesterId = $request->getRequesterId(); // Local ID on originating wiki
$currentUserId = $this->getUser()->getId(); // Local ID on current wiki
if ($currentUserId === $requesterId) {
    // Grant access – no cross-wiki check
}

Patched Code (simplified):

// In SpecialRequestWikiQueue.php
$globalWiki = $wgCreateWikiGlobalWiki;
if ($this->getWikiId() !== $globalWiki) {
    // Deny access – only global wiki can manage requests
    throw new PermissionsError('createwiki');
}
// Additionally, REST API endpoints check $wgCreateWikiDisableRESTAPI

The patch also adds configuration options $wgCreateWikiDisableRESTAPI and $wgConf to disable REST endpoints outside the global wiki.

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Access to a wiki farm with CreateWiki installed (e.g., Miraheze).
• An account on any wiki in the farm.

Steps:

1. Identify a target wiki creation request on a different wiki. Use Shodan dork title:Special:RequestWikiQueue to find exposed instances.
2. Register an account on a wiki where your local user ID matches the target request’s requester ID. This may require trial and error or enumeration.
3. Navigate to https://<your-wiki>/Special:RequestWikiQueue.
4. If your local ID matches, you will see the request and can take actions (approve, reject, etc.).

Proof-of-Concept (No public exploit):

# Hypothetical curl command to approve a request (requires session cookies)
curl -X POST "https://victim-wiki.example.com/Special:RequestWikiQueue/123" \
  -H "Cookie: <session>" \
  -d "action=approve&reason=approved"

Blue Team (Defender)

Detection:

• Monitor Special:RequestWikiQueue access logs for users from unexpected wikis.
• Alert on any approval/rejection actions where the user’s home wiki differs from the request’s originating wiki.

Honeypot:

• Create a fake wiki request with a known user ID. Monitor for any unauthorized access attempts.

Indicators of Compromise (IOCs)

• Log Entries: Special:RequestWikiQueue accessed by user ID X from wiki Y where X matches a request on wiki Z.
• Network: HTTP requests to /w/index.php?title=Special:RequestWikiQueue with unusual Cookie headers.
• File: Modified LocalSettings.php with $wgCreateWikiGlobalWiki not set or set incorrectly.

Detection Engineering

YARA Rule

rule CVE_2024_34701_CreateWiki_Impersonation {
    meta:
        description = "Detects CreateWiki extension files vulnerable to CVE-2024-34701"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-34701"
    strings:
        $vuln_func = "getRequesterId()" nocase
        $vuln_compare = "getId()" nocase
        $vuln_assign = "currentUserId" nocase
    condition:
        all of them
}

Sigma Rule

title: CVE-2024-34701 CreateWiki Impersonation Attempt
id: 8f3a2b1c-5d6e-7f8a-9b0c-1d2e3f4a5b6c
status: experimental
description: Detects access to Special:RequestWikiQueue from a user whose local ID matches a request on another wiki.
author: Valters IT
logsource:
    product: mediawiki
    service: access_log
detection:
    selection:
        uri: "/w/index.php*title=Special:RequestWikiQueue*"
    condition: selection
falsepositives:
    - Legitimate cross-wiki administrators (rare)
level: medium

Suricata Rule

alert http any any -> any any (
    msg:"CVE-2024-34701 CreateWiki Impersonation Attempt";
    flow:to_server,established;
    content:"Special:RequestWikiQueue"; http_uri;
    sid:1000001;
    rev:1;
    reference:cve,2024-34701;
)

Remediation & Mitigation

Immediate:

1. Apply commit 02e0f298f8d35155c39aa74193cb7b867432c5b8 to disable REST API and special pages outside the global wiki.
2. Set $wgCreateWikiGlobalWiki to the central wiki in LocalSettings.php.
3. Configure $wgCreateWikiDisableRESTAPI and $wgConf to restrict access.

Long-term:

• Implement cross-wiki user identity verification (e.g., CentralAuth).
• Audit all extensions for similar local ID assumptions.
• Regularly review access logs for Special:RequestWikiQueue.

Workaround:

• Disable Special:RequestWikiQueue on all wikis except the global wiki using the mw-config commit e5664995fbb8644f9a80b450b4326194f20f9ddc.

Valters IT
DevSecOps & Cyber Threat Intelligence