SemanticMediaWiki from 3.1.0 before 7.3.1 contains a reflected cross-site scripting vulnerability that allows unauthenticated attackers to inject markup through the search parameter of the extended Special:Search profile. Attackers can send visitors crafted URLs using the smw profile with SVG event handlers, which ProfileForm::profilesheet inserts unescaped into a pre element, executing script in the wiki origin.

Semantic MediaWiki from 3.0.0 before 7.3.0 contains a missing authorization vulnerability in the api.php smwtask module that allows unauthenticated attackers to run admin-only maintenance tasks. Attackers can use the public anonymous CSRF token to read internal store statistics, enqueue jobs like smw.entityIdDisposer, and execute queued jobs, degrading performance and altering semantic data.

SemanticMediaWiki from 2.5.0 before 7.3.1 contains a stored cross-site scripting vulnerability that allows users with page-edit rights to inject script through Code-typed property values. Attackers can annotate a valid JSON value embedding HTML markup, which the CodeStringValueFormatter renders unescaped on Special:Browse, executing JavaScript in viewers' sessions.

Semantic MediaWiki from 3.0.0 before 7.3.1 contains a stored cross-site scripting vulnerability that allows users with page-edit rights to inject HTML through Keyword-typed property values rendered unescaped on Special:Browse. Attackers can annotate a Keyword property with an event-handler payload that executes JavaScript in viewers' sessions, including administrators, to read tokens and perform actions.

Semantic MediaWiki from 2.5.0 before 7.3.1 contains a stored cross-site scripting vulnerability that allows users with page-edit rights to inject scripts via External identifier property values. Attackers can annotate markup payloads that ExternalIdentifierValue renders unescaped on Special:Browse, executing JavaScript in viewers' sessions, including administrators.

Semantic MediaWiki from 3.1.0 before 7.3.1 contains a reflected cross-site scripting vulnerability in the Special:SMWAdmin ID lookup that allows unauthenticated attackers to inject markup through the unescaped id parameter. Attackers can lure an smw-admin administrator into opening a crafted lookup link, bypassing the auto-satisfied edit-token check, to execute script and perform privileged actions in the administrator's session.

SemanticMediaWiki from 5.0.0 before 7.3.1 contains a stored cross-site scripting vulnerability in ext.smw.tooltip.tippy.js that renders data- attributes via innerHTML with allowHTML enabled. Editors can plant a .smw-highlighter span with a malicious data-content, data-title, data-top, data-bottom, or data-theme attribute to execute JavaScript when viewers, including administrators, hover it.

Semantic MediaWiki from 3.1.0 before 7.3.1 contains a stored cross-site scripting vulnerability that allows authenticated schema editors to inject HTML through schema descriptions. Attackers with the smw-schemaedit permission can save HTML that is passed unescaped to Html::rawElement() in HtmlBuilder, altering pages and targeting users who view the schema.

Semantic MediaWiki from 3.0.0 before 7.3.1 contains a cross-site scripting vulnerability that allows attackers to inject markup by storing malicious semantic property values rendered unescaped in autocomplete suggestions. When another user opens the property-value autocomplete with an empty query, jquery.autocomplete.js concatenates the raw PValueLookup API value into HTML via container.html(), altering the dropdown and potentially executing script.

Semantic MediaWiki from 4.2.0 before 7.3.1 contains a stored cross-site scripting vulnerability that allows authenticated profile or schema editors to inject HTML through FacetedSearch exploration-link labels. Attackers can store markup in the label, which ExploreListBuilder::buildHTML() passes unescaped to Html::rawElement(), altering the Special:FacetedSearch page and potentially running scripts in viewers' browsers.

Semantic MediaWiki from 3.0.0 before 7.3.1 contains a cross-site request forgery vulnerability in Special:SMWAdmin because it overwrites the wpEditToken with a freshly generated valid token. Attackers can lure an authenticated smw-admin user to a malicious page that triggers schema setup, entity-disposal, or job actions, causing semantic data loss and resource exhaustion.

Semantic MediaWiki from 7.3.0 before 7.3.1 contains a missing authorization vulnerability in the smwtask update task that allows users with edit rights to force semantic updates on arbitrary pages. Attackers can supply a serialized subject parameter for a restricted page to trigger forced reparsing, semantic-store writes, and resource-intensive dependency work.

Semantic MediaWiki from 2.5.0 before 7.3.1 contains an uncontrolled resource consumption vulnerability that allows low-privilege editors to bypass smwgMaxNumRecurringEvents by supplying a large limit parameter. Attackers can save pages using #setrecurringevent without an end date to generate thousands or millions of date subobjects, exhausting CPU, memory, and database resources.

Semantic MediaWiki from 2.5.0 before 7.3.1 contains an uncontrolled resource consumption vulnerability that allows anonymous attackers to force quadratic computation by supplying a zero limit to Special:PropertyLabelSimilarity. Attackers can send repeated requests with limit=0 to bypass the SQL LIMIT and trigger pairwise similartext() comparisons, exhausting PHP CPU, memory, and database connections.

Semantic MediaWiki from 2.5.0 before 7.3.1 contains an improper authorization vulnerability that allows ordinary editors to permanently protect pages by adding an Is edit protected annotation. When $smwgEditProtectionRight is enabled, EditProtectionUpdater applies indefinite edit and move restrictions without checking the author's rights, locking other editors and administrators out.

SemanticMediaWiki from 3.0.0 before 7.3.1 contains a reflected cross-site scripting vulnerability in Special:Ask, which outputs separator parameters (sep, propsep, valuesep, delim, separator) without HTML escaping in list, category, DSV, and CSV result printers. Unauthenticated attackers can send victims crafted Special:Ask links using requesttype=raw or requesttype=specialpage to execute JavaScript in the wiki's origin, stealing sessions or CSRF tokens.

SemanticMediaWiki from 3.1.0 before 7.3.1 contains a reflected cross-site scripting vulnerability that allows unauthenticated attackers to inject scripts through the unescaped default parameter in JsonResultPrinter. Attackers can lure victims to a crafted Special:Ask link with a zero-result query and requesttype=specialpage, executing JavaScript in the wiki origin to steal sessions or CSRF tokens.

Semantic MediaWiki from 7.3.0 before 7.3.1 contains a missing authorization vulnerability in the smwtask API module that allows unauthenticated attackers to run queued jobs and force store updates. Attackers can use the public anonymous CSRF token with run-joblist to execute arbitrary job types in unbounded counts, or invoke update on sysop-protected pages, leaking page titles and exhausting resources.

Semantic MediaWiki 3.0.0 before 7.3.1 contains an uncontrolled recursion vulnerability in LegacyParser::getSubqueryDescription() that processes nested query tokens before depth limits apply. Unauthenticated attackers can submit deeply nested query elements to the action=ask API to consume substantial CPU and memory, tying up request workers.

Semantic MediaWiki from 3.0.0 before 7.3.1 contains an algorithmic complexity vulnerability in TermParser::normalizecompactform() that allows unauthenticated attackers to cause quadratic CPU consumption. Attackers can submit long search terms with many distinct in:(...) or has:(...) expressions to Special:Search to exhaust PHP search workers when the extended search engine is enabled.

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

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 (requesttype=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.

Cross-Site Scripting (XSS) vulnerability reflected in Semantic MediaWiki. This vulnerability allows an attacker to execute JavaScript code in the victim's browser by sending them a malicious URL using the '/index.php/Speciaal:GefacetteerdZoeken' endpoint parameter. This vulnerability can be exploited to steal sensitive user data, such as session cookies, or to perform actions on behalf of the user.