mediawiki/semantic-media-wiki: Special:Ask nested-query parsing recurses before depth limits

Summary

An unauthenticated caller can submit a deeply nested <q>...</q> query to Semantic MediaWiki's action=ask API. LegacyParser::getSubqueryDescription() recursively processes every opening <q> without a parser-depth guard. The configured query-size/depth pruning occurs later, after query-description parsing, so it does not limit this work. A sufficiently nested request can occupy a PHP request worker and consume substantial memory and CPU.

Affected versions

Semantic MediaWiki 3.0.0 through the reviewed 7.3.1-alpha source (61805acbab50e2ffd4f75ebbb23ee9695c191fb8). The recursive parser path is present in the 3.0.0 release line and remains in the current reviewed source. Reported package range: >= 3.0.0.

Preconditions and impact

The wiki must expose the public action=ask API and accept a POST body of about 120 KB. No authenticated account is required on a public wiki. The demonstrated effect is parser CPU and memory consumption before query execution; concurrent requests could reduce capacity by tying up request workers. The local test did not establish a production worker crash or service-wide outage, and deployment body-size limits may affect reachability.

Proof of concept

Use only a disposable local MediaWiki installation at 127.0.0.1; do not send this to a live or third-party service.

q=$(php -r '$n=20000; echo str_repeat("<q>", $n) . "[[Category:Probe]]" . str_repeat("</q>", $n);')
time curl --max-time 10 -sS -X POST 'http://127.0.0.1/api.php' --data-urlencode 'action=ask' --data-urlencode 'format=json' --data-urlencode "query=$q"
unset q

I separately ran a bounded, network-disabled harness against the checked-out LegacyParser code, with lightweight stand-ins for MediaWiki collaborators. Balanced nested wrappers caused parser recursion before any query was executed: depth 1,000 (6,000-byte input) took 12 ms and about 4 MiB peak PHP memory; depth 5,000 (30,000 bytes) took 241 ms and about 10 MiB; depth 10,000 (60,000 bytes) took 966 ms and about 18 MiB; depth 20,000 (120,000 bytes) took 3.69 seconds and about 36 MiB under a 64 MiB memory limit and 8-second wall-clock cap. The HTTP/API integration was source-traced but not run because this checkout has no MediaWiki runtime. No worker crash or live service was tested.

Root cause and remediation

getSubqueryDescription() recurses at each <q> token before Query applies smwgQMaxDepth and size pruning. Enforce a parser nesting limit (and return a controlled query validation error) before descending recursively; add a regression test proving inputs above the limit stop at the parser boundary. A request-length cap is useful defense in depth but does not replace a depth guard.

Source

Repository: https://github.com/SemanticMediaWiki/SemanticMediaWiki Revision: 61805acbab50e2ffd4f75ebbb23ee9695c191fb8

• src/MediaWiki/Api/Ask.php:39-51 — https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/61805acbab50e2ffd4f75ebbb23ee9695c191fb8/src/MediaWiki/Api/Ask.php#L39-L51
• src/Query/Processor/QueryCreator.php:82-95 — https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/61805acbab50e2ffd4f75ebbb23ee9695c191fb8/src/Query/Processor/QueryCreator.php#L82-L95
• src/Query/Parser/LegacyParser.php:282-298 — https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/61805acbab50e2ffd4f75ebbb23ee9695c191fb8/src/Query/Parser/LegacyParser.php#L282-L298
• src/Query/Query.php:472-485 — https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/61805acbab50e2ffd4f75ebbb23ee9695c191fb8/src/Query/Query.php#L472-L485

The currently listed Ask advisories concern different result limits or XSS sinks; the current GitHub advisory list contained no nested-query recursion report.