Semantic MediaWiki has a query debug output XSS (`DebugFormatter`)

An attacker can make query debug output on Special:Ask run attacker-controlled script in a visitor's browser. This reflected XSS requires debug output and a query targeting a text/blob-typed property; the built-in Text property qualifies, so no attacker-created content is needed. No special user right is required, and an anonymous request is sufficient.

Check composer.lock for mediawiki/semantic-media-wiki at version 7.1.0 or earlier; 7.2.0 is fixed. Check whether Special:Ask can return debug output through the debug request parameter for queries targeting text/blob-typed properties, including the built-in Text property. PostgreSQL also exposes query literals through EXPLAIN output, but PostgreSQL is not required for the flaw. Inline {{#ask:...|format=debug}} output is sanitised in parser context and is not the exposed path.

Apply output-context escaping at the DebugFormatter boundary: escape each entry value when emitted, plus the SQL and EXPLAIN strings before wrapping them. Escaping only the query-string echo is insufficient because prettifySQL() and the "Auxilliary Tables" executed-query text carry the same attacker-controlled literals.

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 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).