CVE-2020-25815

The vulnerability resides in the LogEventList::getFiltersDesc method, which constructs HTML option names for a multi-select field using raw message text via ->text() instead of ->escaped(). This means any message content (including dynamic parameters) is injected directly into the HTML without escaping, making the page susceptible to cross-site scripting (XSS) if an attacker can control the message text [1][2].

The attack surface includes any page that renders the log event filter multi-select element, such as Special:Log or similar logging interfaces. An attacker would need the ability to influence the message string that is used as the label for a filter option—this could potentially be achieved through crafted log entries or by exploiting another vulnerability that allows message manipulation. No special authentication role beyond having access to the log page is required to trigger the XSS when the unescaped message is rendered [2][4].

If an attacker successfully injects malicious script content into the message text, it would execute in the context of the victim's browser session. This could lead to session hijacking, defacement, or theft of sensitive data displayed on the page. The impact is consistent with reflected or stored XSS, depending on how the message is sourced, and could affect any user viewing the affected filter interface [3].

MediaWiki addressed this issue in version 1.34.4 (and the earlier 1.34.3 release also includes the fix) by replacing text() with escaped() in the relevant code, ensuring that all dynamic output is properly HTML-escaped [2][4]. The patch also removes an outdated conditional check that was left over from a previous resolved task (T199657), simplifying the logic while improving security [2]. Administrators should upgrade to a fixed version immediately; no workaround is recommended.