MediaWiki CommonsMetadata EUVD-2026-90430

Exploitation requires the MediaWiki CommonsMetadata extension (versions 1.43, 1.45, or 1.46) to be installed and enabled, plus the ability to write attacker-controlled content into file/media metadata that the extension parses and renders. The vendor vector indicates high privileges (PR:H), passive-then-active user interaction (UI:P), and an attack requirement (AT:P), meaning a privileged/authenticated editor must inject the payload and a victim must subsequently view the rendered page. Limiting factors: the extension is an optional add-on (not core MediaWiki), edit/authentication access is needed to plant the payload, victim page-view is required for execution, and impact is confined to Low confidentiality/integrity in the browser context.

This is a low-priority, low-real-risk issue. The vendor's own CVSS 4.0 score is 1.1 - one of the lowest possible for an XSS flaw - driven by a stacked set of limiting metrics (AC:H, AT:P attack requirements, PR:H privileges, UI:P user interaction, and only Low impacts across VC/VI/VA/SC/SI/SA). There is no EPSS score, no CISA KEV listing, and no public exploit code, so exploitation status is 'no public exploit identified at time of analysis.' The E:P (Proof-of-Concept exploit maturity) sub-metric in the vendor vector is a theoretical maturity classification, not evidence of a real POC in the input. My own assessment is that the vendor score understates the flaw somewhat: a stored XSS in a metadata-parsing extension typically needs only edit rights (PR:L) and normal victim page-view (UI:R), not the PR:H/AC:H combination the vendor asserts - see assessed vectors below. Even so, the net risk remains low: impact is bounded to Low confidentiality/integrity in the victim's browser, the affected component is an optional MediaWiki add-on, and no active exploitation or weaponization signal exists.

An attacker with wiki edit privileges injects a script-related HTML payload into file metadata (e.g. a template field the CommonsMetadata extension parses and renders on a file description page). When another user - potentially a reviewer or administrator - views the affected file page, the unsanitized markup executes in their browser session. No public exploit code is available, and the high attack complexity and privilege requirements make opportunistic exploitation unlikely.