GHSA-q5fm-9mx6-44f4 Semantic MediaWiki has a query debug output XSS (`DebugFormatter`)

• Packagist mediawiki/semantic-media-wiki: < 7.2.0 → fixed in 7.2.0

Query debug output XSS Failure mode Semantic MediaWiki's query debug output (`format=debug`, or the `debug` request parameter on `Special:Ask`) is assembled by `SMW\Query\DebugFormatter` and emitted as raw HTML. Several of its sinks apply no output-context encoding, so attacker-controlled query input is reflected into the page without escaping: • `buildHTML()` echoes the re-serialized ASK query string escaping only `[`; ``, `"`, `'` pass through. • `prettifySQL()` returns the generated SQL verbatim. Query value literals are inlined into the SQL through the database layer's quoting (SQL-escaping only, no HTML encoding), so markup in a value survives. • `prettifyExplain()` echoes `EXPLAIN` output; on PostgreSQL the plan text contains the `WHERE` literals. On `Special:Ask` the resulting string is concatenated into the page and sent through `OutputPage::addHTML`, never through the MediaWiki parser or Sanitizer. No special user right is required; an anonymous request suffices. This is a reflected XSS: the payload is taken from the request and echoed in the same response. Exploitation requires the query condition to target a text/blob-typed property (whose value is re-serialized verbatim); the predefined `_txt` properties (`Text`, etc.) that ship on every install satisfy this, so no attacker-created content is needed. Example request: ``` Special:Ask?q=[[Text::alert(document.domain)]]&debug=1 ``` Remediation • Apply output-context escaping at the `DebugFormatter` boundary. The `buildHTML()` contract already assumes its inputs are HTML-safe, but its callers do not honour that; escape each entry value on emission, and the SQL and `EXPLAIN` strings before they are wrapped. • Escaping only the query-string echo is insufficient: `prettifySQL()` and the "Auxilliary Tables" executed-query text carry the same attacker-controlled literals. Scope The `prettifySPARQL()` sink already encodes `` and is not affected. The same debug path is also reachable through inline `{{#ask:...|format=debug}}`, but that output returns into parser context and is sanitized there; the reflected `Special:Ask` path is the exposed sink. Relationship to GHSA-5jhc-3j2f-52rv This issue was identified while splitting the consolidated report GHSA-5jhc-3j2f-52rv into per-vulnerability advisories. It is distinct from the four items in that report (plain table header, `sep`, `SearchByProperty` value, open redirect) and from `Special:Ask` form-input XSS (which is escaped separately).