MediaWiki CVE-2026-58036

Exploitation requires a valid MediaWiki account with at least low-level privileges (PR:L); unauthenticated access is insufficient. Attack complexity is high (AC:H), meaning specific, non-default conditions must align - likely a particular API parameter combination, a specific wiki configuration, or a race/state condition involving PermissionManager or UserGroupManager logic. Passive user interaction (UI:P in CVSS 4.0) is also required, meaning a victim user must perform some action (such as being logged in or triggering a specific state) for the disclosure to occur. Exploitation is limited to low-impact information disclosure (VC:L) with no write or availability impact. Wikis that restrict API access to authenticated users only and limit public registration reduce exposure further.

The CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:L/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N) scores only 2.1, placing this squarely in the low severity band. AC:H indicates non-trivial preconditions for exploitation, and UI:P (passive user interaction in CVSS 4.0 semantics) means a victim user must take some action for the disclosure to occur, further constraining exploitability. Confidentiality impact is limited (VC:L), with no integrity or availability impact. No EPSS data was provided; however, the combination of AC:H, PR:L, UI:P, and a VC:L outcome suggests this would carry a very low EPSS probability if scored. There is no KEV listing and no POC identified. The realistic risk is low: an attacker would need a valid (even minimal) account, specific conditions to be met, and indirect user participation, to gain only a marginal information advantage. This is not a prioritization-worthy vulnerability for most organizations beyond routine patch cycles.

An authenticated MediaWiki user with minimal privileges (such as a standard registered account) crafts an API request to the allusers or users query endpoint under conditions where passive interaction from another user is involved. Because PermissionManager or UserGroupManager fails to correctly gate the response fields for the caller's privilege level, the API returns sensitive attributes - such as group memberships, hidden user details, or internal account flags - that the querying user should not be able to see. No public exploit code is known to facilitate this scenario.