CVE-2023-37253 in ProofreadPage Extension
Summary
by MITRE • 09/14/2026
An issue was discovered in the ProofreadPage extension for MediaWiki through 1.39.3. It leaks information about a suppressed user via the API and config variables.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The ProofreadPage extension, widely utilized within Wikimedia projects to facilitate the transcription of scanned documents into editable text, contains a critical information disclosure vulnerability in versions up to 1.39.3. This flaw stems from insufficient access control mechanisms within the extension's API endpoints and configuration handling routines. Specifically, the software fails to properly validate user permissions when processing requests related to suppressed users, which are accounts that have been hidden by administrators due to severe policy violations or legal requirements. The vulnerability allows an unauthenticated attacker or a low-privileged authenticated user to retrieve sensitive data associated with these restricted accounts through standard API calls and exposed configuration variables.
From a technical perspective, the root cause lies in the extension's failure to enforce strict authorization checks before returning metadata about suppressed users. When an API request is made for page content or related metadata that involves a suppressed user, the backend logic does not adequately mask or reject the response based on the requester's privilege level. Instead, it proceeds to serialize and return data fields that should remain hidden from public view. This includes potentially identifying information such as usernames, edit histories, or other profile details that are normally stripped during standard display operations for suppressed accounts. The exposure occurs because the extension treats certain API parameters with less scrutiny than core MediaWiki functions, creating a discrepancy in security enforcement between different parts of the application layer.
The operational impact of this vulnerability is significant within environments where user privacy and administrative confidentiality are paramount. By exploiting this flaw, an attacker can enumerate suppressed users, effectively bypassing the intended anonymity protections provided by the platform's suppression features. This information leakage aids adversaries in conducting targeted attacks against high-profile individuals or administrators whose identities have been intentionally obscured for safety reasons. Furthermore, the exposure of configuration variables may reveal internal system settings that could assist in crafting more sophisticated exploits against the underlying MediaWiki infrastructure. The breach undermines trust in the platform’s ability to protect sensitive user data and compromises the integrity of administrative actions taken by site operators.
This vulnerability aligns with CWE-200, which classifies information exposure as a flaw where software inadvertently reveals security-relevant information to unauthorized actors. It also maps closely to MITRE ATT&CK technique T1087, specifically Account Discovery, as it enables an attacker to identify valid user accounts that are otherwise hidden from standard enumeration methods. The lack of proper access control on API endpoints reflects CWE-269, indicating a failure in privilege management during the execution phase of the application.
To mitigate this risk, administrators must upgrade the ProofreadPage extension to version 1.39.4 or later, where these authorization checks have been corrected to properly filter responses for suppressed users regardless of the API endpoint used. In cases where immediate patching is not feasible, implementing a Web Application Firewall rule to block specific API parameters associated with user metadata retrieval can provide temporary relief. Additionally, reviewing and tightening general MediaWiki access control policies ensures that no other extensions or core functions expose similar weaknesses. Regular security audits focusing on API response sanitization are recommended to prevent future occurrences of this class of information disclosure vulnerabilities.