- Package
- mediawiki/semantic-media-wiki
- Fixed in
- 7.2.0
- Published
- Fri 18 Sep 2026, 17:58 LisbonUpdated Mon 26 Oct 2026, 00:25 Lisbon
- Installs on Packagist
- 405K
In plain words
An attacker can use a crafted Special:Ask link to run script in a visitor's browser on the wiki's origin. This happens when cursor pagination produces a sort-mismatch error that includes attacker-controlled text as raw HTML. The attacker needs no authentication or special permissions.
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| mediawiki/semantic-media-wiki | >= 7.0.0, <= 7.1.0 | 7.2.0 |
Am I affected?
Look for mediawiki/semantic-media-wiki in composer.lock: versions from 7.0.0 through 7.1.0 are affected, and 7.2.0 is fixed. Check whether your wiki exposes Special:Ask with cursor keyset pagination. The vulnerable error path occurs when the cursor's sort anchor does not match the request's sort or order.
What to do
Check which version you have, then update to a fixed release for your branch (7.2.0):
composer show mediawiki/semantic-media-wiki | grep versions
composer update mediawiki/semantic-media-wiki
If your version constraint in composer.json keeps you below a fixed release, raise it first. Whether your configuration is affected, and the exact version ranges, are in the advisory itself.
If you cannot update yet
Output-encode the attacker-controlled sort_prop and sort_order values in QueryCreator before inserting them into error text. The advisory also says errors added through Query::addErrors() that contain user-controlled text must be output-encoded or use a message key.
The advisory's description
Reflected XSS via a forged cursor pagination token
Failure mode
Special:Ask accepts a cursor query parameter for keyset pagination (added in 7.0.0). The token is decoded by CursorEncoder, which is an unsigned base64url-encoded JSON blob, so its contents are fully attacker-controlled. When the cursor's sort anchor does not match the request's sort= / order=, QueryCreator::applyCursorIfRequested() builds an error message by interpolating the attacker-controlled sort_prop / sort_order values into a raw string via Query::addErrors().
Unlike SMW's message-key errors, this raw string bypasses the message layer's sanitisation (ProcessingErrorMsgHandler::normalizeAndDecodeMessages() passes a non-key, non-encoded string through unchanged). ErrorWidget::queryError() then assembles the errors and passes them to Html::errorBox(), whose first argument is emitted as raw HTML. The result is a reflected cross-site scripting vulnerability: a crafted cursor token containing markup in sort_prop (or sort_order) executes script in the victim's browser on the wiki origin.
No authentication or special permission is required. The payload is delivered via a crafted link, e.g. Special:Ask?q=...&p[cursor]=<forged token> where the token decodes to {"v":1,"sort_prop":"<script>...</script>"}. Confirmed executing in a browser; the responses carry no Content-Security-Policy, so inline script is not blocked.
Remediation
- Output-encode the attacker-controlled
sort_prop/sort_ordervalues before they are interpolated into the error text inQueryCreator, so no raw user input enters the error stream. - Defense in depth: the
format=debugoutput path that reflected the same error text was hardened separately in GHSA-q5fm-9mx6-44f4.
Maintenance note
Query error strings are rendered as raw HTML by ErrorWidget::queryError() via Html::errorBox(). Any error added through Query::addErrors() that embeds user-controlled text must be output-encoded (or use a message key); pagination and validation error text is attacker-influenced and must not be treated as trusted.
Weakness: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').
The advisory
- GitHub Advisory Database: GHSA-cx86-7xwp-w9wf, with who is affected and how
- OSV.dev: GHSA-cx86-7xwp-w9wf
- The week's digest, with the other advisories from 14 Sep 2026
- All advisories for mediawiki/semantic-media-wiki