p PatchFirst

PatchFirst · Latest vulnerabilities

mediawiki vulnerabilities · Page 9

Vulnerabilities published for mediawiki in the last 30 days: 11. Listed in the KEV catalogue: 0.

Filter vulnerabilities
Clear filters

Vulnerabilities: 180

  1. CVE-2021-30158

    Medium · CVSS 5.3EPSS 1.73%No fix published

    CVE-2021-30158

    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.

    Published Updated
  2. CVE-2020-35480

    Medium · CVSS 5.3EPSS 1.49%No fix published

    CVE-2020-35480

    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.

    Published Updated
  3. CVE-2020-35477

    Medium · CVSS 5.3EPSS 1.71%No fix published

    CVE-2020-35477

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

    Published Updated
  4. CVE-2020-35475

    High · CVSS 7.5EPSS 1.59%No fix published

    CVE-2020-35475

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

    Published Updated
  5. CVE-2020-25827

    High · CVSS 7.5EPSS 1.7%No fix published

    CVE-2020-25827

    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.

    Published Updated
  6. CVE-2020-25828

    Medium · CVSS 6.1EPSS 1.09%No fix published

    CVE-2020-25828

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

    Published Updated
  7. CVE-2020-25814

    Medium · CVSS 6.1EPSS 1.35%No fix published

    CVE-2020-25814

    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.

    Published Updated
  8. CVE-2020-15005

    Low · CVSS 3.1EPSS 1.3%No fix published

    CVE-2020-15005

    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.

    Published Updated

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →