CVE-2026-77610

## 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::<script>alert(document.domain)</script>]]&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 `>` and is not affected. The same