GHSA-Q5FM-9MX6-44F4
Vulnerability from github – Published: 2026-09-18 16:53 – Updated: 2026-09-18 16:53Query 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()echoesEXPLAINoutput; on PostgreSQL the plan text contains theWHEREliterals.
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
DebugFormatterboundary. ThebuildHTML()contract already assumes its inputs are HTML-safe, but its callers do not honour that; escape each entry value on emission, and the SQL andEXPLAINstrings 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).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.1.0"
},
"package": {
"ecosystem": "Packagist",
"name": "mediawiki/semantic-media-wiki"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-77610"
],
"database_specific": {
"cwe_ids": [
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-18T16:53:23Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Query debug output XSS\n\n#### Failure mode\n\nSemantic MediaWiki\u0027s 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:\n\n- `buildHTML()` echoes the re-serialized ASK query string escaping only `[`; `\u003c`, `\u003e`, `\"`, `\u0027` pass through.\n- `prettifySQL()` returns the generated SQL verbatim. Query value literals are inlined into the SQL through the database layer\u0027s quoting (SQL-escaping only, no HTML encoding), so markup in a value survives.\n- `prettifyExplain()` echoes `EXPLAIN` output; on PostgreSQL the plan text contains the `WHERE` literals.\n\nOn `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.\n\nThis 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:\n\n```\nSpecial:Ask?q=[[Text::\u003cscript\u003ealert(document.domain)\u003c/script\u003e]]\u0026debug=1\n```\n\n#### Remediation\n\n- 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.\n- Escaping only the query-string echo is insufficient: `prettifySQL()` and the \"Auxilliary Tables\" executed-query text carry the same attacker-controlled literals.\n\n#### Scope\n\nThe `prettifySPARQL()` sink already encodes `\u003c` and `\u003e` 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.\n\n#### Relationship to GHSA-5jhc-3j2f-52rv\n\nThis 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).",
"id": "GHSA-q5fm-9mx6-44f4",
"modified": "2026-09-18T16:53:23Z",
"published": "2026-09-18T16:53:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/SemanticMediaWiki/SemanticMediaWiki/security/advisories/GHSA-q5fm-9mx6-44f4"
},
{
"type": "PACKAGE",
"url": "https://github.com/SemanticMediaWiki/SemanticMediaWiki"
},
{
"type": "WEB",
"url": "https://github.com/SemanticMediaWiki/SemanticMediaWiki/releases/tag/7.2.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Semantic MediaWiki has a query debug output XSS (`DebugFormatter`)"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.