MEDIUM 6.5

CVE-2026-58027: Wikimedia AbuseFilter Information Disclosure Vulnerability

A Wikimedia Foundation AbuseFilter component is exposing sensitive information that should be restricted to authorized users. The vulnerability requires an authenticated user to trigger, and affects the API filter query functionality. While the issue doesn't allow attackers to modify data or disrupt service, the confidentiality impact is significant—affected versions leak information through the includes/Api/QueryAbuseFilters.Php file that authenticated users shouldn't access.

Source data · NVD / CISA · public domain

CVSS
3.1 · 6.5 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Weaknesses (CWE)
CWE-200
Affected products
2 configuration(s)
Published / Modified
2026-07-01 / 2026-07-09

NVD description (verbatim)

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Wikimedia Foundation AbuseFilter. This vulnerability is associated with program files includes/Api/QueryAbuseFilters.Php. This issue affects AbuseFilter: from * before 1.46.0, 1.45.4, 1.44.6, 1.43.9.

1 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-58027 is an information disclosure vulnerability (CWE-200) in Wikimedia's AbuseFilter extension. The flaw exists in the QueryAbuseFilters API endpoint and allows authenticated actors to retrieve sensitive data due to insufficient access controls. The vulnerability requires network access and authentication but no user interaction. CVSS 3.1 score is 6.5 (MEDIUM) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, indicating high confidentiality impact confined to the affected component's scope.

Business impact

Organizations operating MediaWiki instances with AbuseFilter enabled may expose sensitive moderation and filter configuration details to authenticated users who lack proper authorization. This could compromise the integrity of spam and abuse detection strategies, reveal internal policy logic, or expose metadata about site moderation that could be weaponized by bad actors with legitimate wiki accounts. The impact depends on deployment context—public wikis with open registration face higher risk than private knowledge bases.

Affected systems

The vulnerability affects Wikimedia Foundation AbuseFilter in versions before 1.46.0, 1.45.4, 1.44.6, and 1.43.9. All releases prior to these patch versions are vulnerable. The issue is associated with the includes/Api/QueryAbuseFilters.Php program file. AbuseFilter integrates with MediaWiki, so any MediaWiki instance using AbuseFilter from an affected version line is in scope.

Exploitability

Exploitability is moderate. An attacker must already possess valid authentication credentials to the MediaWiki instance—this eliminates unauthenticated attack vectors. No special privileges are required; a regular authenticated user can trigger the information disclosure. The attack is straightforward once authenticated and requires no user interaction or complex conditions. However, the requirement for authentication substantially reduces the attack surface compared to unauthenticated vulnerabilities.

Remediation

Update AbuseFilter to a patched version immediately: 1.46.0 or later, 1.45.4 or later, 1.44.6 or later, or 1.43.9 or later, depending on your current release line. The patches implement proper authorization checks on the QueryAbuseFilters API endpoint to prevent information disclosure to unauthorized actors. Verify the patch version against the official Wikimedia Foundation advisory before deployment.

Patch guidance

1. Identify your current AbuseFilter version via Special:Version on your MediaWiki instance. 2. Determine which release line you operate: 1.46.x, 1.45.x, 1.44.x, or 1.43.x. 3. Update to the minimum patched version for that line: 1.46.0+, 1.45.4+, 1.44.6+, or 1.43.9+. 4. Test the patch in a staging environment, particularly the AbuseFilter API endpoints, to confirm no disruption to legitimate moderation workflows. 5. Roll out to production during a maintenance window to minimize user impact. 6. Post-deployment, verify via Special:Version and audit API access logs for any anomalous QueryAbuseFilters requests from before the patch date.

Detection guidance

Monitor access logs for queries to Special:AbuseFilter/query or API calls to action=query&list=abusefilters, particularly from low-privilege user accounts. Look for repeated or unusual attempts to enumerate or retrieve filter details. If you can access MediaWiki debug logs, check for CWE-200 or authorization bypass patterns in the QueryAbuseFilters endpoint. A security review of recent API access—especially between the vulnerability publish date (2026-07-01) and your patching date—can identify whether the flaw was exploited in your instance.

Why prioritize this

Medium CVSS (6.5) warrants prompt but not emergency response. The confidentiality impact is high, but authentication is required and there is no integrity or availability impact. Prioritize if: your wiki permits untrusted user registrations; your AbuseFilter rules contain sensitive policy or blacklist logic; you operate a public-facing MediaWiki; or your instance houses proprietary knowledge. Deprioritize if your wiki is private and only trusted users can register. The lack of CISA KEV listing suggests no active in-the-wild exploitation as of publication, reducing urgency relative to critical flaws.

Risk score, explained

The CVSS score of 6.5 reflects the combination of network-accessible attack vector, low attack complexity, and high confidentiality impact, offset by the requirement for authenticated access and absence of integrity or availability consequences. The score appropriately places this in the Medium band—serious enough to patch promptly but not an emergency comparable to remote code execution or privilege escalation flaws. Organizations should treat this as a high-priority maintenance item rather than an emergency.

Frequently asked questions

Can an unauthenticated attacker exploit this vulnerability?

No. The vulnerability requires valid authentication credentials to a MediaWiki instance. Unauthenticated users cannot trigger the information disclosure. This significantly reduces the attack surface.

What information is exposed by this vulnerability?

The vulnerability discloses sensitive AbuseFilter details through the QueryAbuseFilters API endpoint, including filter logic, configurations, and metadata that should be restricted to administrators and authorized moderators. The exact scope depends on your filter configuration and what data you store.

Is there any indication this vulnerability has been actively exploited?

As of the vulnerability publication date, CVE-2026-58027 is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, suggesting no evidence of active in-the-wild exploitation. However, absence from KEV does not guarantee non-exploitation; monitor your instance for suspicious access patterns.

Do I need to patch if I don't use AbuseFilter?

No. This vulnerability only affects MediaWiki instances with the AbuseFilter extension installed and enabled. If AbuseFilter is not deployed, this CVE does not impact your installation. Verify your extensions via Special:Version.

This analysis is based on published vulnerability data and vendor advisories current as of the source data date. CVSS scores and patch version numbers are derived from official sources and should be verified against the latest Wikimedia Foundation security advisories before deployment. SEC.co does not provide legal liability or compliance advice. Organizations are responsible for assessing risk within their own environment and applying patches according to their change management policies. No exploit code or detailed attack steps are provided. For the most current information, consult the official Wikimedia Foundation security page and the CVE record. Source: NVD (public-domain), retrieved 2026-08-10. Analysis generated by SEC.co (claude-haiku-4-5).