PatchFirst · Latest vulnerabilities
Vulnerabilities published for mediawiki in the last 30 days: 9. Listed in the KEV catalogue: 0.
Vulnerabilities: 295
An issue was discovered in Wikimedia Parsoid before 0.11.1 and 0.12.x before 0.12.2. An attacker can send crafted wikitext that Utils/WTUtils.php will transform by using a <meta> tag, bypassing sanitization steps, and potentially allowing for XSS.
An issue was discovered in MediaWiki before 1.31.12 and 1.32.x through 1.35.x before 1.35.2. On Special:NewFiles, all the mediastatistics-header-* messages are output in HTML unescaped, leading to XSS.
An issue was discovered in MediaWiki before 1.31.12 and 1.32.x through 1.35.x before 1.35.2. On ChangesList special pages such as Special:RecentChanges and Special:Watchlist, some of the rcfilters-filter-* label messages are output in HTML unescaped, leading to XSS.
An issue was discovered in MediaWiki before 1.31.12 and 1.32.x through 1.35.x before 1.35.2. Blocked users are unable to use Special:ResetTokens. This has security relevance because a blocked user might have accidentally shared a token, or might know that a token has been compromised, and yet is not able to block any potential future use of the token by an unauthorized party.
An infinite loop in SMLLexer in Pygments versions 1.5 to 2.7.3 may lead to denial of service when performing syntax highlighting of a Standard ML (SML) source file, as demonstrated by input that only contains the "exception" keyword.
In pygments 1.1+, fixed in 2.7.4, the lexers used to parse programming languages rely heavily on regular expressions. Some of the regular expressions have exponential or cubic worst-case complexity and are vulnerable to ReDoS. By crafting malicious input, an attacker can cause a denial of service.
MediaWiki before 1.35.1 allows XSS via BlockLogFormatter.php. Language::translateBlockExpiry itself does not escape in all code paths. For example, the return of Language::userTimeAndDate is is always unsafe for HTML in a month value. This affects MediaWiki 1.12.0 and later.
An issue was discovered in MediaWiki before 1.35.1. Missing users (accounts that don't exist) and hidden users (accounts that have been explicitly hidden due to being abusive, or similar) that the viewer cannot see are handled differently, exposing sensitive information about the hidden status to unprivileged viewers. This exists on various code paths.
MediaWiki before 1.35.1 blocks legitimate attempts to hide log entries in some situations. If one sets MediaWiki:Mainpage to Special:MyLanguage/Main Page, visits a log entry on Special:Log, and toggles the "Change visibility of selected log entries" checkbox (or a tags checkbox) next to it, there is a redirection to the main page's action=historysubmit (instead of the desired behavior in which a revision-deletion form appears).
MediaWiki before 1.35.1 allows XSS via BlockLogFormatter.php. MediaWiki:blanknamespace potentially can be output as raw HTML with SCRIPT tags via LogFormatter::makePageLink(). This affects MediaWiki 1.33.0 and later.
In MediaWiki before 1.35.1, the messages userrights-expiry-current and userrights-expiry-none can contain raw HTML. XSS can happen when a user visits Special:UserRights but does not have rights to change all userrights, and the table on the left side has unchangeable groups in it. (The right column with the changeable groups is not affected and is escaped correctly.)
In MediaWiki before 1.35.1, the combination of Html::rawElement and Message::text leads to XSS because the definition of MediaWiki:recentchanges-legend-watchlistexpiry can be changed onwiki so that the output is raw HTML.
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, Special:UserRights exposes the existence of hidden users.
An issue was discovered in the OATHAuth extension in MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4. For Wikis using OATHAuth on a farm/cluster (such as via CentralAuth), rate limiting of OATH tokens is only done on a single site level. Thus, multiple requests can be made across many wikis/sites concurrently.
An issue was discovered in MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4. The non-jqueryMsg version of mw.message().parse() doesn't escape HTML. This affects both message contents (which are generally safe) and the parameters (which can be based on user input). (When jqueryMsg is loaded, it correctly accepts only whitelisted tags in message contents, and escapes all parameters. Situations with an unloaded jqueryMsg are rare in practice, but can for example occur for Special:SpecialPages on a wiki with no extensions installed.)
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, XSS related to jQuery can occur. The attacker creates a message with [javascript:payload xss] and turns it into a jQuery object with mw.message().parse(). The expected result is that the jQuery object does not contain an <a> tag (or it does not have a href attribute, or it's empty, etc.). The actual result is that the object contains an <a href ="javascript... that executes when clicked.
An issue was discovered in MediaWiki 1.32.x through 1.34.x before 1.34.4. LogEventList::getFiltersDesc is insecurely using message text to build options names for an HTML multi-select field. The relevant code should use escaped() instead of text().
An issue was discovered in MediaWiki 1.34.x before 1.34.4. On Special:Contributions, the NS filter uses unescaped messages as keys in the option key for an HTMLForm specifier. This is vulnerable to a mild XSS if one of those messages is changed to include raw HTML.
In MediaWiki before 1.31.8, 1.32.x and 1.33.x before 1.33.4, and 1.34.x before 1.34.2, private wikis behind a caching server using the img_auth.php image authorization security feature may have had their files cached publicly, so any unauthorized user could view them. This occurs because Cache-Control and Vary headers were mishandled.
In MediaWiki before 1.34.1, users can add various Cascading Style Sheets (CSS) classes (which can affect what content is shown or hidden in the user interface) to arbitrary DOM nodes via HTML content within a MediaWiki page. This occurs because jquery.makeCollapsible allows applying an event handler to any Cascading Style Sheets (CSS) selector. There is no known way to exploit this for cross-site scripting (XSS).
Check your installed stack and versions against the current vulnerability feeds.