WordPress

An Easy Way to Check If You Are Using Vulnerable Versions of Revolution Slider, Showbiz Pro, and Other WordPress Plugins

When it comes to the security of WordPress, despite lots of misinformation and outright fear mongering, the security is quite good. The developers of WordPress have been quite good at handling security, and when a security issue is found they promptly respond to the issue and the fully automatic update mechanism for security updates included since WordPress 3.7 means that those security updates are promptly applied for most websites. Unfortunately the handling of security of plugins isn’t as good. While most of the vulnerabilities found in plugins are unlikely to lead to your website being hacked, there are some that are easily exploitable. In most cases simply updating your plugins when WordPress notifies you of a new version will protect you (or setting them to automatically update with our Automatic Updates Plugin or another similar tool), but there are a couple of situations where that isn’t true.

The first situation is where a plugin that is in the wordpress.org Plugin Directory has a vulnerability that isn’t’ fixed. Once the people running Plugin Directory are informed of the issue they will pull the plugin. That will prevent anyone more from installing the plugin but leaves everyone already running the plugin vulnerable as they are not provided any warning. We have been pushing for that to be changed for several years, but that still hasn’t happened. If you would like to see that change then please vote for that to happen.

The second situation is where a vulnerability exists in a plugin that isn’t in the wordpress.org Plugin Directory. While it is possible for these plugins to be hooked into WordPress’s normal update mechanism that isn’t always done, leaving the admin of the website to be unaware of a new version with a security fix being available.

For the first situation, we have for some time provided a plugin that lists installed plugins that have been removed from the directory and in some cases also includes a security advisory. For the second situation, we have new plugin that can help with that by warning if versions of plugins with known vulnerabilities are installed in WordPress.

Let’s take a look at how that works. Recently the Revolution Slider and Showbiz Pro plugins have been getting a lot of attention for a couple of security issues that existed in older versions. The first vulnerability allowed the viewing of arbitrary files (that could be exploited to view the database credentials stored in the wp-config.php file), that impacts Revolution Slider versions 4.1.4 & below and Showbiz Pro versions 1.5.2 & below. The second and much more serious vulnerability allows malicious files to be uploaded on to the website, that impact Revolution Slider versions 3.0.95 & below and Showbiz Pro versions 1.7.1 & below. If you have our Plugin Vulnerabilities plugin installed and you have one of those versions of Revolution Slider or Showbiz Pro installed you will see an alert message on the Installed Plugins page like this:

alert message shown for vulnerability in Revolution Slider

In addition to the vulnerabilities in Revolution Slider and Showbiz Pro our plugin currently has data on 116 vulnerabilities. That is still a small portion of all the plugin vulnerabilities out there, but we are continuing to add additional vulnerabilities. This week we added 30 vulnerabilities to the plugin. Going back to the first situation where plugin have been removed from the wordpress.org Plugin Directory the plugin also helps with that as we have data on security vulneabilities in the most recent versions of 24 plugins, which have been removed from the Plugin Directory.

With the plugin you can also see vulnerabilities that have existed in other versions of plugins you have installed from the Plugin Vulnerabilities page in the Plugin menu.

Wordfence and WPScan Acted Irresponsibly With WordPress Plugin Vulnerability

Several years ago we noted a pretty big problem when it came to the security of WordPress plugins; many plugins with known security vulnerabilities in their most recent version were still available in the wordpress.org Plugin Directory. That was a big failure as making sure that those vulnerabilities were fixed or the plugin was pulled until it was fixed was such a low hanging fruit towards better plugin security. For a while after that we were keeping a watch for unfixed vulnerabilities to make sure that wasn’t occurring, but after a while we were simply too busy with services unrelated to security of WordPress that we didn’t have time to do this anymore. Recently we again had time to focus on the security of WordPress plugins, as part of that we started working a new plugin, Plugin Vulnerabilities, which lets you know of security vulnerabilities that exist and existed in the plugins you have installed.

When we started working on the plugin we quickly found that the issue of plugins with known vulnerabilities in their most recent versions still being available in the wordpress.org Plugin Directory hasn’t gone away. In less than a month we have helped to get known vulnerabilities in seven plugins fixed by either contacting the developers of the plugins – who in many are not notified by the person who discovered the vulnerability – or letting the people running the Plugin Directory know that a vulnerability exists in the plugin. Some of them were rather serious, one that we mentioned before involved a backup plugin that permitted any logged in user to download backups made by the plugin. In that case within a day of us passing along the issue to the Plugin Directory people the issue was resolved, that was after almost a month had gone by since the developer had been notified of the issue and two weeks after it was made public.

While looking into another vulnerability we found something more troubling. On September 10 a claimed vulnerability was disclosed in the plugin Rich Counter. In late November when we took a look at it to verify that it was real before add it to our plugin, we found that as described the exploit didn’t work. To exploit the vulnerability it said you should change your web browser’s user agent to “Mozilla<script>alert(document.cookie)</script>”. For us it didn’t work that way, but it did work if you removed “Mozilla” from the start of the user agent. We were somewhat curious as to what had happened to cause a situation where a vulnerability was correctly identified but the explanation of the exploitation of it to not work. We thought it might be case where someone else had actually discovered the issue and someone else was trying to take credit for it. We didn’t find anything to explain the situation, but while doing that we found that several WordPress related security projects had mentioned the disclosure of the vulnerability. We are rather troubled that they were aware of the vulnerability but had not made sure it was fixed or the plugin was pulled from the directory. What made this worse was that within days of us alerting the developer to the issue a partial fix was made and after further message the issue appears to be fully fixed. It would have been quite easy for them to have done the same, but they didn’t leaving website vulnerable when they didn’t have to be, so we feel it is worth highlighting their irresponsible behavior.

First up is Wordfence, which sells a WordPress security service. They mentioned the vulnerability back on October 30 in a post about plugins with vulnerabilities they wanted “to draw your attention to”, unfortunately they were more interested in drawing your attention to their website then actually drawing the attention of the developer to the issue who would have actually fixed the issue if they had contacted them as we did (or if the developer was unwilling at that time Wordfence should have then contacted the WordPress.org Plugin Directory about it).

The other place we found it mentioned was the in WPScan Vulnerability Database, a website that lists WordPress vulnerabilities, in an entry added on October 18. Again this came from someone selling WordPress security services and the project is also sponsored by another security company Sucuri. You have to question why security companies would be in the business of providing wider notice of security vulnerabilities in WordPress plugins but not letting the developer, who could actually fix the issue, or the people at the Plugin Directory know about the issue if their interest was truly in security versus making you more vulnerable and then selling you their security services.

Security Vulnerability Fixes Often Left Unmentioned In WordPress Plugin Changelogs

When it comes to security companies, we often see that they seem less interested in actually improving security than getting themselves attention. In some cases the harmful effects of this are quite obvious, like when a security companies falsely implicates a piece of software as being a common connection between a group of hacked websites leading people to believe that software is insecure when it isn’t. A less obvious situation where this attention seeking comes in to play is when a security company warns that you need to update a WordPress plugin since it has a security vulnerability. What could be the problem with that you are probably thinking? The answer is that you need to update all of your plugins in a timely manner, and not try to keep track of what ones might have a security vulnerability and therefore need to be updated immediately. The reason for this is that there is a good chance that you won’t be able to tell if an update fixes security vulnerability, even if you review the changelog for plugin (which in turn is more likely to warn you about security issue than following any security company).

Recently we started working on a new plugin, Plugin Vulnerabilities, that provides information on vulnerabilities that exist and previously existed in the plugins you have installed in WordPress. One of the places we look at when determining what versions of a plugin are susceptible to a vulnerability is the plugin’s changelog. In doing that we have found that the amount of details provided in the changelog when a security issue is fixed varies widely. In many cases the fact that a vulnerability has been fixed is disclosed (sometimes with basic details of the vulnerability include as well), but in plenty of cases there is no mention at all that a security vulnerability has been fixed.

To get a better idea how frequently security vulnerability fixes are left out of the changelog, we went through the vulnerabilities currently listed in our Plugin Vulnerabilities plugin for which the relevant plugin is currently in the wordpress.org Plugin Directory and tallied up whether the vulnerability being fixed was mentioned in the changelog or not. In our sample of 66 plugin updates, we found that in 19.7 percent of them the changelog made no mention of a vulnerability being fixed. The breakdown of the changelog mentions are as follows:

43 updates listed that a vulnerability fix was included
10 updates mentioned that a fix for a potential or possible vulnerability was included (in all cases the vulnerability was in fact exploitable)
13 updates made no mention of a vulnerability being fixed

Jut based on the fact that you have about a 1/5 chance that a security fix isn’t mentioned in changelog, not updating plugins all the time seems like a bad idea, but what is more important is how severe the vulnerabilities fixed that are not mentioned can be. Take for instance version 5.2.91 of Special Text Boxes plugin, which had the following listed as the change made in the release:

The possibility of manipulating custom themes has been removed by request of administration of wordpress.org plugins repository.

Would you have guessed that referred to fixing an arbitrary file upload vulnerability that was being actively exploited before 5.2.91 was released? Probably not.

The Security Risks That Could Be Lurking in Your WordPress Backup Plugin

One of the things that we have noticed in looking at security vulnerabilities in WordPress plugins over the years is that backup plugins are often found to have vulnerabilities. While working on our new plugin that lets you know what vulnerabilities are or have in the past existed in the WordPress plugins you use we have seen that the poor security of backup plugins is continuing. Two examples highlight the problems with security of not just backup plugins, but all plugins.

DB Backup Plugin

Because backup plugins create files containing sensitive data, backup plugins need to prevent unauthorized users from downloading those files. One way to do that is block direct access to the files and then permit users to download them through the plugin. Unfortunately that can introduce a new security risk since if the download mechanism is not secured it can be abused to download files that someone shouldn’t have access to. That is the case with the plugin DB Backup, which was found to allow anyone to download arbitrary files from the website. That could for example be used to download the wp-config.php and therefore provide the login credentials for the website’s database.

The bigger problem that this highlights is what happens when a security vulnerability doesn’t get fixed, as is the case with this plugin. Right now if you go to the page for this plugin https://wordpress.org/plugins/db-backup/ you get served a search page:

This is due to the plugin being pulled from the Plugin Directory, probably due to someone notifying WordPress of the issue. This prevents anyone from downloading the plugin, but what about people that already have it installed? Unfortunately they are not given any notice that they are using a plugin with a security vulnerability. That obviously shouldn’t be the case, but despite our pushing for that to change for years WordPress still has corrected this issue. If you would like to see that change then please vote for that to happen.

XCloner – Backup and Restore

Another general problem with plugins is that the developers don’t always have much concern for security. The developer of the XCloner – Backup and Restore plugin falls in to that category, which has put the users of the plugin at risk in multiple ways.

The most recent vulnerability discovered in the plugin allowed any one who could log in to WordPress to download any backup files created by XCloner. What is of more concern is the developer’s response. The person who discovered vulnerability states that they notified the developer on November 7 and 13, the vulnerability wasn’t fixed after either of those. It also wasn’t fixed after the vulnerability was publicly disclosed on November 19. It finally got fixed within a day of us reporting the vulnerability to WordPress and the plugin being pulled pending a fix. You can see they only had to make minor changes to fix the issue, so this could have easily been fixed before if they had been interested. If we hadn’t reported the vulnerability it is quite possible the vulnerability still wouldn’t have been fixed.

This isn’t an isolated incident. Below is the list of the unsuccessful attempts a security company made to notify of them of vulnerabilities in a standalone version of XCloner:

– 6 notifications by email
– 4 notifications via contact form
– 1 notification via twitter.

The latest vulnerability is one of five that have been discovered in the plugin. The others are:

The developer’s lack of concern for security isn’t just for their software, seeing as their website is currently running a nearly four year old version of WordPress:

6Scan Is Bad At Detecting Malicious Code

From dealing with lots of hacked websites one of things that we know is that detecting malicious code through automated processes isn’t very effective. The variety of code makes it difficult, but what makes it much more difficult is that often the code appears to be designed to be able to avoid detection from these automated processes (which in turn usually makes it easy for a human to spot). Unfortunately other companies dealing hacked website haven’t figured this out or are not interested in making sure the websites they deal with get fully cleaned and secured, leading to many instances where we are hired to re-clean up hacked websites after they have failed to get the job done. One of the latest examples we saw was of a web host using 6Scan on a hacked website. 6Scan describes their services as “Powerful Automated Website Protection” and they describe their ability find malicious code with the following, “You might not be aware if your site has already been compromised, but our scanner will recognize the traces hackers leave behind. You’ll see immediate results—as comprehensive as they are easy to understand—displayed on our dashboard.”. Though, from what we saw it is at least a rather poor malicious code scanning tool.

At the point we were brought what had happened is that the web host for the website would detect the website was sending spam emails, suspend it, run 6Scan on it and remove the files they detected as malicious, and then after some amount of time spam email would get sent out again and the process would start over. What a quick check of the website’s files showed was that 6Scan was not detecting much of the malicious code and that meant the hacker still had access after the code they were detecting was removed. Considering that the web host in question is touted on 6Scan’s homepage as one of their “Trusted Partners” we don’t think that they were doing something wrong in use of the tool that lead to the poor detection.

The 6Scan scan that was run right before we did our clean up detected 54 files with malicious code and missed the malicious code in 40 other files, so their detection rate was not very good at only 57 percent. What was more surprising is how easy to spot most of the files they missed were. Many of the files were stored in the wp-admin and wp-includes directories of a WordPress website. Since those two directories generally should only contain files that come with WordPress any additional files would be a red flag. In other cases malicious code was added to core WordPress files that shouldn’t be modified, which also would be a red flag. In both cases someone reviewing the results of a file comparison with a clean install of WordPress would have easily noticed the malicious code, while 6Scan’s automated processes did not.

There are a few of important takeaways from this. First, if someone says they are going to clean up a hacked website with automated tools, you are going to want to find someone else to do it. You might get lucky with a hack that is rather simple and the malicious code gets fully detected, but if you don’t then it is going to mean multiple cleanups and in some cases more problems. It also important to hire someone that will determine how the website was hacked in the first place, as doing that and fixing the vulnerability is the way to protect against the hack happening again (that was certainly important for us to fully clean up the website in this instance). The final one is that you should avoid 6Scan as they either don’t understand that the service they provide can’t do what they claim or they know that it can’t don’t care. Instead you should spend your time and money on making sure you do things that will actually protect your website from being hacked in the first place, so someone like us doesn’t have to clean up after it gets hacked.

jQuery.com is Running Outdated and Insecure Version of WordPress

Today it was reported that website of the JavaScript library jQuery was recently hacked. When a high profile website like this is hacked what is important to find out is how it was hacked, since a high profile websites are sometimes hit with new exploits that will later be exploited more widely and making sure that others are warned early can help to limit further successful exploitation. Unfortunately that has not been determined so far, the article states that “The bad news is that they still don’t know how the compromised happened, so it just might happen again.”.

Right now the jQuery website has a pretty obvious security problem. They are running an outdated version of WordPress:

The next version of WordPress, 3.9.2, which was released on August 6, included a number of security fixes and users were “strongly encourage you to update your sites immediately”. We are not aware of a mass exploitation of those vulnerabilities (or any others in older versions of WordPress in years), but some of the vulnerabilities fixed might be exploitable in a targeted attack. Back in WordPress 3.7, a new feature was introduced that automatically applies maintenance and security updates, like WordPress 3.9.2, so most websites that had been running WordPress 3.9.1 would have been upgraded within a day of the release of 3.9.2. That means that either the jQuery web developers disabled that feature or their server has some issues preventing the automatic updates from occurring. (Those automatic updates can be extended to plugins with our Automatic Plugin Updates plugin.)

Unfortunately the use of outdated software on the jQuery website isn’t an uncommon occurrence, when we looked at data from one of our tools earlier this year we found that 60 percent of WordPress were running a version below the then current version (we also found widespread use of outdated version of Drupal and Joomla.). A good way to keep track of the update status of websites you manage is with our Up to Date? Chrome app.

ManageWP Shows Lack of Concern for Security by Running Insecure Version of WordPress

When it comes to the security of websites, what we see over and over is that the basics are not even being handled by people that shouldn’t have a problem doing it. If you are running a WordPress website then part of Security 101 is keeping WordPress up to date, as it prevents your website from being hacked due to a known vulnerability in an older version of WordPress. Unfortunately, that isn’t being done in many cases as can been seen in the fact that only 40 percent of WordPress websites were running the latest series of WordPress in the data set we looked at in March.

You would think that providing better management tools would help this situation, though the example of one of the providers of such a tool would say otherwise. ManageWP describes its services as providing you the ability to “Manage all your WordPress sites from one place – including updates, backups, security and more.” You would certainly expect they would be keeping the WordPress installation powering their website up to date, but they’re not:

WordPress 3.5.2 is over ten months out of date and there have two subsequent releases with security updates (3.6.1 and 3.8.2).

ManageWP’s failure to take handle a basic security task is sharp contrast to their claims of security. For example, they claim

Securing ManageWP and the sites we interact with has always been our highest priority. We use state-of-the-art encryption and security standards that go above and beyond what WordPress, itself, offers, to ensure that your sites are protected.

On another page they make a series of claims about their security:

How ManageWP Is Secure

We have a full-time security specialist

We regularly perform penetration testing

No credit card information stored

No WordPress passwords stored

OpenSSL encryption

ManageWP is built on top of WordPress

Account password encryption

White hat reward program

If you are security specialist who fails to make sure such a basic security measure is taken then you probably should find another profession.

Another bad sign for their concern for security is their integration of Sucuri.net’s deeply flawed malware scanning into their service.

30 Percent of WordPress Plugins Haven’t Been Updated by Their Developers in Over Two Years

Two years ago we created a plugin that list any installed WordPress plugins that have been removed from the WordPress.org Plugin Directory. There are a number of reasons that plugins are removed, the most important being when it has a security vulnerability. For that reason WordPress should alert when a plugin has been removed, until that occurs our plugin can be used to check if any installed plugins have been removed.

Recently it was suggested that the plugin also list plugins that have not been updated by their developers for over two years as well. On the Plugin Directory website, plugins that have not been updated in over two years have a banner at the top of the page that states “This plugin hasn’t been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.”. Even plugins that have not needed any changes should have been updated periodically to indicate that they are compatible with new versions of WordPress. For the reasons listed in the banner it would be helpful to those already running the plugin to be aware the situation as well.

One of things we looked at before deciding to add a listing of plugins that had not been updated in over two years was how many plugins fall in to this category. We first checked a small sample and found that many of the plugins fell in this category. When we looked at all of the plugins we found that was still the case. As of yesterday a total of 12,703 plugins had not been updated in over two years. That is 30 percent of all the plugins that have entries in the Subversion Repository for the Plugin Directory. Not all plugin entries have actually been used, so the percentage of plugins that people could being using is probably higher.

Below we have charted what year these plugins were last updated. The number for 2012 is lower as plugins last updated after March 9 of 2012 would still under two years out of date.

WordPress Plugins That Have Not Been Updated in Over Two Years: 2004 7, 2005 150, 2006 63, 2007 450, 2008 1319, 2009 2523, 2010 3364, 2011 3710, 2012 1117 Today we released a new version of the plugin that lists installed plugins that have not been updated in over two years. If you want to check if you are using any plugins that have not been updated in over two years install our No Longer in Directory plugin (available through the Add new page in the WordPress admin area) and then in the admin area go to the plugin’s page in the Plugins menu. The page will list any installed plugins that have been removed for the directory first and then any plugins that have not been updated in over two years.

Automatically Updating Plugins in WordPress

In WordPress 3.7 a new feature was introduced that causes WordPress to automatically apply minor updates to WordPress (for example, going from 3.7 to 3.7.1). The underlying system that handles that also supports doing automatic updates for major updates, plugin updates, and theme updates as well. The reason for limiting it to minor updates by default makes a lot of sense, because there is a process in place for minor updates to make sure there is a little chance as possible for something going wrong. The lead developer of WordPress describes the process as:

Background updates are incredibly, incredibly safe. Sites already running WordPress 3.7 have attempted more than 110,000 updates without a single critical failure, thanks to a number of verification steps that have made updates that much more reliable. A background update for a minor or security release (which is all they are enabled for, by default) means downloading and copying over just a few files. We’ve gotten really good at that. We’ve also spent years honing our craft of shipping stable and targeted fixes in minor releases — we don’t indiscriminately backport bug fixes. They must be serious bugs, and fixes go through additional levels of review, including at least two lead developers. And, we have the ability to roll out an automatic update over a period of hours or days. For 3.7.1, we’ll likely see how a few hours of user-initiated updates go before telling about 1% of sites to update, then steadily increase that percentage.

Depending on the situation of an individual website enabling other updates to occur automatically as well makes sense. Keeping plugins up to date is an important as it prevents the website from being exploited due to a vulnerability in an outdated version of the plugin. At this point we haven’t seen a vulnerability in WordPress that is likely to lead to the average website being hacked in years, but with plugins that isn’t the case. So keeping plugins up to date is at least as important as keeping WordPress up to date. If you use plugins that have a good track record of not breaking after an update (we haven’t had any issues with the plugins we use on our blogs over many years) then it can make sense to turn on automatic updates for plugins.

Turning on automatic plugin updates can be accomplished by adding the following line to functions.php of your current theme:

add_filter( 'auto_update_plugin', '__return_true' );

If you prefer not to modify your theme you have another option with our new plugin, Automatic Plugin Updates, which enables automatic plugin updates along with providing a couple of additional features. The lesser additional feature is that it turns on email notifications for those automatic plugin updates (this can be disabled). The bigger feature is that it enables disabling automatic updates for selected plugins. This can be useful if you have modified plugins in use or if you have plugins that you are more concerned that an update could cause problems with the website. While you can roll your own code to do this as well, with our plugin you don’t have to worry about changes being made in the process of handling excluding plugin from automatic updates. As of the current beta of WordPress 3.9 the process has changed from previous versions, causing code written for the old versions to not stop the automatic update from happening, and our plugin is already ready to handle that if the change remains in the production release of 3.9. Both of the additional features can be accessed on the plugin’s setting page:

Automatic Plugin Updates Settings Page

Outdated Versions of Joomla 2.5.x and 3.x Widely Used

Last month we spotlighted at the fact that 31 percent of Joomla websites checked with our Joomla Version Check tool during January were still running Joomla 1.5, for which supported ended September 2012. This month we decided to take a look at if websites that were running a supported Joomla series, either 2.5.x or 3.x, were being kept up to date based on last month’s data from the tool. Unlike websites still running Joomla 1.5 that need a more complicated migration to be brought up to a supported version, the upgrade process for websites running 2.5.x or 3.x is relatively simple. Keeping software running on a website up to date is a basic security measure, so if websites are not being kept up to date when it is relatively easy it shows that website security is in bad shape.

Joomla 2.5.18 was released during the month so Joomla 2.5.x websites would have been up to date if they running 2.5.17 or 2.5.18. Unfortunately 58 percent of the Joomla 2.5 websites were detected as running older versions (for some installations the tool only could tell they were using Joomla 2.5 and those listed as 2.5.x in the chart).

Joomla Version: 2.5.x: 12.30%, 2.5.0: 0.53%, 2.5.1: 1.60%, 2.5.2: 0.53%, 2.5.3: 0.53%, 2.5.4: 4.28%, 2.5.6: 6.95%, 2.5.7: 3.74%, 2.5.8: 5.88%, 2.5.9: 10.16%, 2.5.11: 9.09%, 2.5.13: 1.07%, 2.5.14: 9.63%, 2.5.15: 0.53%, 2.5.16: 3.74%, 2.5.17: 15.51%, 2.5.18: 13.90%

54 percent of the Joomla 2.5 websites checked contain known security vulnerabilities, as they are running versions below 2.5.15, the most recent release with security fixes.

For Joomla 3.x the results are slightly better as only 48 percent were detected running versions prior 3.2.1 or 3.2.2 (3.2.2 was release during the month alongside 2.5.18).

Joomla Version 3.x: 6.35%, 3.0.2: 3.17%, 3.0.3: 6.35%, 3.0.4: 1.59%, 3.1.1: 14.29%, 3.1.4: 1.59%, 3.1.5: 14.29, 3.2.0: 6.35%, 3.2.1: 26.98%, 3.2.2: 19.05%

41 percent of the Joomla 3.x websites checked contain known security vulnerabilities, as they are running versions below 3.1.6, the most recent release with security fixes.

Outdated WordPress and MediaWiki Versions Heavily Used Too

The results for the WordPress and MediaWiki websites checked during February using our tools for those pieces software were also not good.

For WordPress, 60 percent of the websites checked were running a version below the current series, 3.8.

WordPress Version: 2.5: 0.93%, 2.9: 0.46%, 3.0: 0.93%, 3.1: 1.39%, 3.2: 2.78%, 3.3: 6.02%, 3.4: 6.02%, 3.5: 15.28%, 3.6: 10.65%, 3.7: 15.74%, 3.8: 39.81%

For MediaWiki, 47 percent of the websites checked were running a series no longer supported. The currently supported versions are 1.19.x, 1.21.x, and 1.22.x.

MediaWiki Version: 1.14: 3.77%, 1.15: 7.55%, 1.16: 9.43%, 1.17: 9.43%, 1.18: 7.55%, 1.19: 18.87%, 1.20: 9.43%, 1.21: 15.09%, 1.22: 16.98%, 1.23: 1.89%