MediaWiki CentralNotice EUVD-2026-89504

Exploitation requires the CentralNotice extension to be installed and enabled on a MediaWiki instance (a non-default add-on, predominantly used on Wikimedia-style deployments) at a version before 1.46.1, 1.45.5, or 1.43.10. The attacker must be able to store a payload via a CentralNotice banner/campaign field - in typical configurations this requires the centralnotice-admin user right, making the injection step effectively privileged despite the vendor's PR:N. Successful impact also requires victim user interaction (UI:R): another user must load a page that renders the malicious banner. Impact is limited to partial confidentiality/integrity in the victim's browser context (C:L/I:L, no availability impact).

Signals converge on a genuinely moderate-to-low real-world priority. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N = 6.1) reflects a classic stored XSS: network-reachable, low complexity, but requiring victim user interaction (UI:R) and yielding only partial confidentiality/integrity impact (C:L/I:L, no availability). CISA's SSVC framework reinforces low urgency - Exploitation: none, Automatable: no, Technical Impact: partial - meaning no observed exploitation and no wormable/scriptable mass-exploitation path. There is no EPSS score, no KEV listing, and no public exploit code. One point of friction: the vendor scored PR:N (unauthenticated), but injecting a stored payload into CentralNotice banners normally requires a privileged 'centralnotice-admin' right, so the practical injection step is likely authenticated - this should be verified against the Gerrit patch, and if confirmed it lowers realistic risk further (see assessed vector PR:L). This is a real, patch-worthy web vulnerability but not an emergency; it is a moderate-CVSS issue with low real-world exploitation pressure.

An attacker who can edit or create a CentralNotice banner/campaign injects a crafted script payload into a field that is rendered unescaped during page generation. When another wiki user (potentially an administrator) loads a page that displays the malicious banner, the script executes in their browser session, enabling session/token theft or actions in their context. No public exploit code or active exploitation is known at time of analysis.