A number of cross-site scripting (XSS) security vulnerabilities were discovered in the web-based installer (config/index.php). These vulnerabilities all
require a live installer -- once the installer has been used to install a wiki, it is deactivated.

Note that cross-site scripting vulnerabilities can be used to attack any website in the same cookie domain. So if you have an uninstalled copy of MediaWiki on the same site as an active web service, MediaWiki could be used to attack the active service.

If you are hosting an old copy of MediaWiki that you have never installed, you are advised to remove it from the web.

David Remahl of Apple's Product Security team has identified a number of security issues in previous releases of MediaWiki. Subsequent analysis by the MediaWiki development team expanded the scope of these vulnerabilities. The issues with a significant impact are as follows:

A CSRF vulnerability affecting the Special:Import feature, for all MediaWiki installations since the feature was introduced in 1.3.0. [CVE-2008-5252]

XSS (cross-site scripting) vulnerabilities allow an attacker to steal an authorised user's login session, and to act as that user on the wiki. The authorised user must visit a web page controlled by the attacker in order to activate the attack. Intranet wikis are vulnerable if the attacker can determine the intranet URL, even if the attacker cannot access it.

CSRF vulnerabilities allow an attacker to act as an authorised user on the wiki, but unlike an XSS vulnerability, the attacker can only act as the user in a specific and restricted way. The present CSRF vulnerability allows pages to be edited, with forged revision histories. Like an XSS vulnerability, the authorised user must visit the malicious web page to activate the attack.

Rather than backport our SVG validation code to this ancient branch, we have instead disabled SVG uploads. To enable SVG uploads, please upgrade to MediaWiki 1.13.3 or later.

This is a security and bug-fix update to the Spring 2006 quarterly release.

An XSS injection vulnerability based on Microsoft Internet Explorer's UTF-7 charset autodetection was located in the AJAX support module, affecting MSIE users on MediaWiki 1.6.x and up when the optional setting $wgUseAjax is enabled.

If you are using an extension based on the optional Ajax module, either disable it or upgrade to a version containing the fix:

1.9: fixed in 1.9.3

1.8: fixed in 1.8.4

1.7: fixed in 1.7.3

1.6: fixed in 1.6.10

There is no known danger in the default configuration, with $wgUseAjax off.

Add 'charset' to Content-Type headers on various HTTP error responses to forestall additional UTF-7-autodetect XSS issues. PHP sends only 'text/html' by default when the script didn't specify more details, which some inconsiderate browsers consider a license to autodetect the deadly, hard-to-escape UTF-7. This fixes an issue with the Ajax interface error message on MSIE when $wgUseAjax is enabled (not default configuration); this UTF-7 variant on a previously fixed attack vector was discovered by Moshe BA from BugSec: http://www.bugsec.com/articles.php?Security=24

MediaWiki 1.6.7 is a security and bugfix maintenance release of the Spring 2006 snapshot:

An HTML/JavaScript-injection vulnerability in the edit form has been closed.
This vulnerability was new in 1.6.0; MediaWiki versions 1.5.x or earlier are not affected.

Extensions, comments, and <nowiki> sections are now handled in a one-pass way which is more reliable and safer. Under earlier versions of MediaWiki, certain extensions could be abused to inject HTML/JavaScript into the page.

Additional precautions are made against offsite form submissions when the restricted raw HTML mode is enabled.

Nesting of different tag extensions and comments should now work more consistently and more safely. A cleaner, one-pass tag strip lets the 'outer' tag either take source (<nowiki>-style) or pass it down to further parsing (<ref>-style). There should no longer be surprise expansion of foreign extensions inside HTML output, or differences in behavior based on the order tags are loaded.

An XSS injection vector in brace replacement has been fixed, as have some potential problems with table parsing. Upgrading is strongly recommended for all users of 1.6. MediaWiki versions 1.5 and earlier are not affected.

Additionally some localization and user interface updates are included.

MediaWiki is now using a "continuous integration" development model with quarterly snapshot releases. The latest development code is always kept "ready to run", and in fact runs our own sites on Wikipedia.

Release branches will continue to receive security updates for about a year from first release, but nonessential bugfixes and feature development will take place on the development trunk and will appear in the next quarterly release.

Several changes to the database have been made from 1.5; these are relatively minor but do require that the update process be run before the new code will work properly:

A new "templatelinks" table tracks template inclusions.

A new "externallinks" table tracks URL links; this can be used by a mass spam-cleanup tool in the SpamBlacklist extension.

A new "jobs" table stores a queue of pages to update in the background; this is used to update links in including pages when templates are edited.

To ensure that these tables are filled with data, run refreshLinks.php after the upgrade.

If you are upgrading from MediaWiki 1.4.x or earlier, some major database changes are made, and there is a slightly higher chance that things could break. Don't forget to always back up your database before upgrading!

Some output, particularly involving user-supplied inline HTML, may not produce 100% valid or well-formed XHTML output. Testers are welcome to set $wgMimeType = "application/xhtml+xml"; to test for remaining problem cases, but this is not recommended on live sites. (This must be set for MathML to display properly in Mozilla.)