CVE-2024-47913

What it actually does

An API caller can evaluate filter conditions against AbuseFilter logs without authorization to view the underlying log details, bypassing intended access controls on log data.

Why it matters to the business

Attackers may obtain unauthorized visibility into abuse detection rules and historical log matches, increasing the risk of targeted evasion or data exposure in wiki environments.

How an attack unfolds

An attacker with API access crafts a query that references AbuseFilter log conditions; the server evaluates the match without enforcing view permissions on the log entries, returning partial results that leak filter logic or activity.

How to fix it

Upgrade MediaWiki AbuseFilter to versions 1.39.9, 1.41.3, 1.42.2 or later; apply the commit 35e6747afdebbf565d03bfc261c547a9cbad6e70 for git deployments. The unrelated gofiber template component should be updated to 3.1.9 if present.

How to confirm the fix worked

Confirm the installed MediaWiki and AbuseFilter version against the fixed releases, then attempt an API query referencing a restricted filter to verify that authorization checks now block unauthorized log matching.

Typical attack path

1. Obtain API credentials or unauthenticated access to the MediaWiki instance
2. Identify the AbuseFilter extension endpoint
3. Submit an API request that references a protected filter condition against logs
4. Receive match results that disclose information normally restricted by view permissions

How to detect it

Review MediaWiki API request logs for AbuseFilter actions that reference filter conditions; look for queries succeeding where view permissions should have denied access.

What your security team should do

• Prioritize upgrade of the AbuseFilter extension within the next maintenance window due to the authorization bypass
• Audit API access logs for AbuseFilter endpoints to establish a baseline of normal queries
• Review filter visibility settings and restrict API permissions to the minimum required roles