Semantic MediaWiki EUVD-2026-110717

Requires Semantic MediaWiki installed and enabled, plus an account with ordinary page-edit rights (no special right is needed because the Code type is user-selectable from the contextual type group); on wikis that permit anonymous editing this becomes reachable without authentication. The attacker must declare a property of type Code and store a value that begins with '{' and parses as valid JSON while embedding HTML in a JSON string - the '{'-prefix JSON branch is what routes to the vulnerable asJson() path (non-JSON Code values are escaped and are not exploitable). Exploitation is LIMITED by required passive victim interaction (UI:P): a payload fires only when another user actually opens Special:Browse for the annotated subject, so there is no automatic server-side execution. Impact escalation to administrator actions depends on a privileged user viewing the specific annotated page and is described by the vendor as plausible, not demonstrated.

This is a medium-severity stored XSS (CVSS 4.0 base 5.3) whose real-world risk is moderate and bounded, not a top-tier emergency. The signals are internally consistent and point to limited, non-automated exploitation: the input CVSS 4.0 vector is AV:N/AC:L/AT:N/PR:N/UI:P, meaning network-reachable and low-complexity but requiring passive user interaction (a victim must view the annotated Special:Browse page), with only Low confidentiality and integrity impact and no availability impact. The vendor priority Decision label is 'this_month' (not act_now/emergency), which aligns with a stored client-side flaw rather than a wormable server compromise. KEV status is not present in the input, so this is 'no public exploit identified' in the active-exploitation sense - BUT a public PoC reference exists: the GHSA advisory (GHSA-6v7f-crgp-hhvp) and the VulnCheck advisory contain full step-by-step reproduction; this PoC reference is not verified here as packaged, working standalone exploit code. No EPSS score was provided, so exploitation probability cannot be quantified from the input - STATE EXPLICITLY: EPSS missing. There is a notable data conflict on fix state: the description, EUVD, and the final metadata line say the flaw is fixed in 7.3.1 and a vendor patch is 'Available', yet the GitHub source-code evidence snapshot states 'not fixed / no fixed release exists at time of review' with 7.3.0 as latest checked - the source-review snapshot predates the 7.3.1 fix, so treat 7.3.1 as the authoritative fixed version but verify against the current vendor release. The PR metric also warrants scrutiny: the input used PR:N reflecting wikis that allow anonymous editing, but the advisory states exploitation normally requires ordinary page-edit rights, so on authenticated-edit wikis a low privilege is in fact required. Net: a credible, documented, but interaction-dependent and privilege-dependent vulnerability - patch on the normal cycle, prioritize if anonymous editing is enabled or privileged users routinely browse user-annotated subjects.

On a wiki running Semantic MediaWiki, an attacker with page-edit rights (or any anonymous user where open editing is enabled) declares a property of type Code and annotates a JSON value embedding markup, e.g. [[Example::{"x":"<img src=x onerror=alert(document.domain)>"}]]. When another user - potentially an administrator - later opens Special:Browse for that subject, the CodeStringValueFormatter emits the markup unescaped and the script runs in the viewer's authenticated session under the wiki origin. A detailed public PoC reference is included in the GHSA advisory; it is not verified here as standalone working exploit code.