MediaWiki CentralAuth EUVD-2026-89486

Exploitation requires the attacker to store a malicious script payload into a field handled by the MediaWiki CentralAuth extension (the global/unified account-management extension used in multi-wiki farms), on an installation running a version before 1.46.1, 1.45.5, or 1.43.10. The attack is gated by victim interaction (UI:R): a user must view the page rendering the stored payload for the script to execute, and the scope change (S:C) means the script runs in the victim's authenticated browser session. The vendor rates privileges as PR:N, but because this is stored XSS the payload must first be persisted - confirm the exact injection path (e.g., an account/global-rename field reachable without privileges) against the Wikimedia advisory. Limiting factors: deployment is restricted to sites that specifically run CentralAuth (not plain MediaWiki), a fix is already available, and no automation or active exploitation is indicated (SSVC Automatable=no, Exploitation=none).

This is a moderate-severity stored cross-site scripting flaw (CVSS 6.1) in the MediaWiki CentralAuth extension, and all available signals point to a real-but-not-urgent issue rather than a high-priority emergency. The CVSS vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N) describes network-reachable, low-complexity injection that fires in a victim's browser after they view the poisoned content (UI:R), with a scope change (S:C) reflecting that injected script executes in the user's authenticated session context, and only partial confidentiality/integrity impact (C:L/I:L, no availability impact). CISA's SSVC framework reinforces the lower urgency: Exploitation=none (no observed activity), Automatable=no (requires victim interaction, not mass-automatable), and Technical Impact=partial - consistent with a typical stored XSS rather than a wormable or server-compromising bug. No EPSS score, no KEV listing, and no public exploit were provided, so this is 'no public exploit identified at time of analysis.' One point of tension: the vendor vector sets PR:N (unauthenticated), yet stored XSS normally requires the attacker to first persist a payload into some stored field, which often implies at least an account or an unauthenticated-but-stored input path (e.g., account-creation or global-rename metadata) - verify the exact injection vector with the Wikimedia advisory/Phabricator ticket before assuming fully unauthenticated storage. A fix is confirmed available from the vendor across the 1.46.1 / 1.45.5 / 1.43.10 branches.

An attacker persists a malicious script payload into a CentralAuth-managed field that is later rendered in another user's browser; when a victim (potentially a privileged global account administrator) views the affected page, the script executes in their authenticated session (S:C), enabling session/cookie theft or actions on their behalf (C:L/I:L). Exploitation requires the victim to view the poisoned content (UI:R) but is low-complexity (AC:L); no public exploit code was identified at the time of analysis.