Category Archives: WordPress

Many WordPress Plugin Vulnerabilities Have Not Been Fixed

As of today’s release, our Plugin Vulnerabilities plugin includes entries for 200 security vulnerabilities that have existed in WordPress plugins. While that is far from all of the vulnerabilities out there, it does include a good mix of vulnerabilities. So far we have focused on adding newly discovered vulnerabilities, vulnerabilities that we are seeing exploit attempts for, and vulnerabilities from the archives of security researchers. We have included some stats we collected on those vulnerabilities below.

One stat stands out, over a quarter of the vulnerabilities – 54 of 200 – have not been fixed. A few of these were only recently discovered or the developer was only recently informed of them (all too often no one bothers to inform the developer and this is something that our work on the plugin has been rectifying), but for the vast majority there has been ample time and notice to the developer so they should have been fixed by now. This is a big problem because simply keeping plugins up to date won’t protect you if the latest version of the plugin has a known security vulnerability that can be exploited.

Right now what happens when a vulnerability isn’t fixed is that the plugin will be removed from the Plugin Directory until it is fixed, assuming the people running the Plugin Directory are informed of the issue. That does nothing for any websites that already have the plugin installed though. It is a problem we have been highlighting for three years now, without getting a solution. It also has been over two years since there was indication that a solution was being worked on. We hope that it won’t take another year to finally get fixed. In the meantime you can use our Plugin Vulnerabilities plugin to get alerted to known vulnerabilities in installed plugins and our No Longer in Directory plugin to find out what installed plugins have been removed from the Plugin Directory.

Plugin Vulnerability Stats As of March 2, 2015

  • 200 vulnerabilities included
  • 54 included vulnerabilities are in the most recent version of plugins (49 of these plugins have been removed from the Plugin Directory)
  • 14 vulnerabilities have been fixed in part due to our work on this plugin
  • 5 included vulnerabilities in security plugins
  • Top vulnerability types:
    • cross-site request forgery (CSRF)/cross-site scripting (XSS): 49 vulnerabilities
    • reflected cross-site scripting (XSS): 39 vulnerabilities
    • unrestricted file upload: 31 vulnerabilities
    • arbitrary file viewing: 16 vulnerabilities
    • SQL injection: 15 vulnerabilities
  • Top vulnerability discoverers:
Posted in WordPress Plugins | Leave a comment Makes It Harder For Security Journalists to Hype WordPress Plugin Vulnerabilities

Last Wednesday we discussed an ongoing issues where security journalist conflate WordPress plugin’s download count at with how many websites are using the plugin, making a vulnerability seem like it has much larger impact than it actual it does. In the case last week the headlines proclaimed things like “More than 1 million WordPress websites imperiled by critical plugin bug” about a security vulnerability that existed in older versions of WP Slimstat, beyond explaining the fact that the security vulnerability in question was unlikely to be widely exploited, we pointed out that the website count used was way off base. The journalist were taking the 1.3 million downloads the plugin had and using that to back up their claim on over 1 million websites impacted, which they shouldn’t have since it isn’t close to being appropriate substitute for an actual count of use.

Over the weekend made a change that should stop this, as they started displaying a count of Active Installs in addition to download counts for WordPress plugins. In the case of the WP Slimstat plugin the actual number of websites using it is much less than a million, with the Active Installs listed at 100,000+:


Hopefully this will be a wake-up call to some of those journalist that they need to stop taking so many liberties when reporting on WordPress plugin security issues, since this isn’t the only problem that there has been with their coverage of the issue (which could use more quality coverage).

Posted in Bad Security, WordPress Plugins | Leave a comment

One Easy Step To Hype A WordPress Plugin’s Security Vulnerabilty

We would love to see more quality press attention to the issue of WordPress plugin security because there certainly is much discuss, unfortunately, as with security journalism in general, when it does get discussed these days the reporting is mostly awful. Take for instance the Ars Technica article More than 1 million WordPress websites imperiled by critical plugin bug (written by the same person who last year wrote an article that we found to be completely baseless).

The words imperiled and critical are probably not appropriate, considering that the vulnerability in WP Slimstat was fixed in an update last week (you can turn of WordPress ability to automatically updates plugins with one of our plugins) and due to the type of vulnerability. The vulnerability is a blind SQL injection vulnerability, which can allow data to be read out of the database. While this has the potential to be rather serious if you store sensitive data on the website, this type of vulnerability isn’t often exploited by hackers that are not targeting specific websites (most hacks are not targeted). So the chances of it being exploited are rather small in comparison to say a vulnerability that allows PHP files to be uploaded to a website, which we can almost guarantee is going to be exploited, most likely sooner rather than later. The chances of this plugins vulnerability being exploited are even slimmer because it requires a fair amount computing being done before you can exploit it, unlike plenty of other blind SQL injections that have been found in WordPress plugins.

The big problem with the article comes from the claim in the title that “more than 1 million WordPress websites imperiled”. Over a million websites impacted make this sounds like a major issue, the problem is that it isn’t close to being true. If you read through the article nothing is provided that backs that number up, instead only the download count of the plugin is mentioned:

WP-Slimstat is an analytics tool. Its listing on WordPress shows it has been downloaded more than 1.3 million times. People who operate websites that use the plugin should update immediately.

Downloads of software obviously are not the same as how many websites are using software, so treating them the same is something a journalist concerned about accuracy wouldn’t be doing. But what makes it so bad for WordPress plugins is that each time a plugin gets updated through the WordPress admin area that counts as new download, so the actual user count is going to be much smaller than the download count, especially if the plugin is updated frequently. The download graph for one of our plugins dramatically shows how updates impact the download count:


You see that huge spike that on the graph, that is when we updated the plugin. On that day there were 148 downloads and the next day there 47 the next day. That compares to 9 downloads a day we averaged over the last week. Those two days work out to 13 percent of total downloads so far.

WP Slimstat is updated more often so there are lots of spikes on the graph, of which, most if not all are due to updates:


Ars Technica isn’t alone in this, a quick search pulled up more articles on this vulnerability with the same highly inflated website use count:

It also worth mentioning that this type of article has the potential to be somewhat harmful to security since you need to being keeping your WordPress plugins update to date all the time instead of trying to be on the lookout for mentions of fixed security issues since security fixes often are not even mentioned in plugins’ changelogs.

Posted in Bad Security, WordPress Plugins | Leave a comment

WordFence Really Doesn’t Know What They Are Talking About

One of the biggest problems we see with improving the security of websites is the amount of bad information out there, as it is hard to start to address the underlying problems when so much of what is being said is wrong. What surprised us when we started dealing with security issues is how much of that bad information comes from security companies. We don’t have the time to go through every instance of this since it is so widespread, but it is worth looking at an example of a company putting out bad information from time to time when a larger security issue is also raised.

On February 11, security researcher Claudio Viviani publicly disclosed a SQL injection vulnerability in the WordPress plugin WORDPRESS VIDEO GALLERY. According to his advisory he had notified the developer of the plugin about the issue two days before that. The next Tuesday we added the vulnerability to our Plugin Vulnerabilities plugin and on Friday, after waiting a few days to give time to the developer to release the fix, we notified the people running the Plugin Directory of that the vulnerability existed and had not been fixed. Following that the plugin was pulled from the directory. Earlier today they let us know the plugin had been removed and that the fixed version should be available soon. While checking to confirm that issue was fixed in the new version, which it was, we came across a forum thread that linked to a WordFence, which sells a WordPress security service, blog post entitled Zero Day SQL Injection Vulnerability in WordPress Video Gallery.

The problems with their blog post start with the title. This vulnerability wasn’t a zero day vulnerability since that involves a vulnerability being exploited before the developer or the public knows about the vulnerability. That wasn’t the case here as the vulnerability was publicly disclosed a week before and it appears the developer knew about it before that. The implications of a zero day vulnerability are much different than what this actually is, so the distinction is important. Zero day vulnerabilities do get more press coverage, so you might ask if they characterized it that way to try to get them attention.

That wasn’t the end of the problems, it continues into the content of the post:

There is currently a zero day SQL injection vulnerability in the WordPress Video Gallery plugin. Our researchers are seeing exploits in the wild for this and the exploits claim the vendor has been notified on the 9th of February.

If you click the “exploits in the wild” link what you get is not anything to do with exploits of the vulnerability in the wild, instead it is a copy of Claudio Viviani’s advisory on the Exploit Database website. The advisory itself doesn’t provide any code to exploit vulnerability. The proof of concept (POC) given simply shows where the SQL injection code would go:


It doesn’t include any malicious SQL code and providing the POC doesn’t really make much difference in exploiting the vulnerability since with the details of the vulnerability someone should be able to recreated the provided POC quite easily.

You really have to wonder about the competency of the WordFence researchers when they are claiming that a security advisory is somehow evidence of “exploits in the wild”.

Also in that section they half acknowledge the developer was notified of the vulnerability ahead of the exploitation, which would mean that this isn’t a zero day vulnerability as they are claiming.

The plugin still has not been updated by the vendor. Because this is being exploited actively and the vendor has been notified, we are now publicly disclosing the existence of this vulnerability.

WordFence isn’t actually publicly disclosing anything since the person that discovered the vulnerability already did that, it isn’t clear if they don’t know what public disclosure actually is or if they are intentionally trying to take credit for something they didn’t do.

A ‘googledork’ is also available in the exploit which allows attackers to use Google to find sites which suffer from this vulnerability in order to exploit them.

While this might sound ominous it doesn’t really mean much, the “googledork” in this case is simply a search query that shows URLs in Google’s index that are from RSS feature of this plugin. Here it is from the advisory:

# Dork Google: inurl:/wp-admin/admin-ajax.php?action=rss

Again this doesn’t actually matter much since all the search query does is show indexed URLs that contain the start of the path that is exploited:


Protecting Against Unfixed Vulnerabilities in WordPress Plugins

The situation with this plugin does get to a real problem, how do we protect against websites being hacked when known vulnerabilities in WordPress plugins are not fixed. WordFence’s solution beyond reporting the issue to the Plugin Directory, seems to be more effective at promoting their website then dealing with this type of situation:

Please share/tweet/mail this to your fellow WordPress administrators to help create awareness about this serious issue.

We have been pushing for a better approach to handling than this type of situation for years, which would involve WordPress warning admins when an installed plugin has been removed from the Plugin Directory (if you would like to see that happen please vote for it on the WordPress Ideas website). Until that happens you can use our No Longer in Directory plugin that provides a more limited version of that functionality. For this type of situation though one of our other plugins, Plugin Vulnerabilities, is more useful. This plugin warns when installed plugins have known security issue and also provides information on vulnerabilities that existed in other versions, which is useful when cleaning up a hacked WordPress website. Last Tuesday we updated the plugin to warn about this security vulnerability, so if you had our plugin installed and you had version 2.7 of the WORDPRESS VIDEO GALLERY plugin installed you would have then seen the following warning on the Installed Plugins page:

Plugin Vulnerabilities Screenshot

Posted in Bad Security, WordPress Plugins | Leave a comment

Lessons from the FancyBox for WordPress Plugin Vulnerability

Last week a vulnerability in the WordPress plugin Fancybox for WordPress was exploited causing many websites to serve malware. A week later we thought it would be a good time to look at what went wrong and what lessons can be taken from the incident to hopefully improve WordPress plugin security going forward.

WordPress Plugin Security is in Bad Shape

When we started to look in to this, what we were most interested to see was what was the underlying vulnerability that allowed the websites to be hacked. Was it some obscure corner case that allowed a hacker access they shouldn’t have or was it some very fundamental failure? Since the developer stated they fixed the vulnerability in version 3.0.3 looking at the changes in that version was the starting place for understanding that. What the changes made show is that anyone could change the plugin’s settings. By anyone we truly me anyone, you didn’t have to be logged in to WordPress to change the settings. This wasn’t the intention of the developer, as can be see by the fact that only logged in users who are Administrators can access the plugin’s settings page.

The problematic code is the code for saving the settings, which did not check to make sure that the settings change came from the setting’s page. In 3.0.2 the code simply checked if a request for a setting updates was sent and then went on to save the settings:

if ( isset($_REQUEST[‘action’]) && ‘update’ == $_REQUEST[‘action’] ) {

The changed code in 3.0.3 checks to see where the request came from as well:

if ( isset($_REQUEST[‘action’]) && ‘reset’ == $_REQUEST[‘action’] && check_admin_referer( ‘mfbfw-options-options’ ) ) {

In many cases being able to change a plugin’s settings would not allow it to be used to serve malware. What allowed it in this cases is that the plugin has settings that allow additional code to be added to pages in which FancyBox for WordPress is present:

Fancybox for WordPress Extra Calls Settings Page

All the hacker had to do was to update the settings to turn on that feature and have it use their malicious code.

The fact that a plugin that now has over 600,000 downloads (each time an installed plugin is updated in WordPress that gets included in the download count, so the amount of websites using it is much lower) allowed anyone to change it’s settings and a hacker was the first person to discover this isn’t a good sign for the security of WordPress plugins. We think that Automattic has at least some responsibility for improving this situation.

The response after the fact was much better. The vulnerability was quickly fixed and WordPress automatically pushed the updated version for those running at least WordPress 3.7 (which introduced automatic updates)

Understanding the Scope of Vulnerability

When dealing with a hacked website an important element in the cleanup process is understanding the scope of the exploitation, so that appropriate cleanup action is taken. While it doesn’t hurt to do more than what is needed, it can take more time and increase expenses, which can be a major hardship depending on the website.

In this case the direct impact of the vulnerability is somewhat limited. The hacker is able to add code to the setting and that is loaded on pages on the website but because the setting is stored in the database safely using the update_option function they can not otherwise gain access the database through the vulnerability. It is possible for malicious JavaScript to provide the hacker additional access to the website if an admin was to have visited a page that has the code on it while logged in.

Once a website upgraded to at least version 3.0.4, any malicious code currently stored in the setting is disabled and the vulnerability is patched, so the website should be secure at that point, but you may want take the precautionary measures of changing the passwords associated with the website and checking over the website for malicious code or reverting the website to a backup made before the website was originally hacked.

The Settings API

When looking at how to improve code security, hoping that people will start writing secure code on their own isn’t a good bet. Some combination of making it easier to do things securely and making it harder to write insecure code seems to be an important element to improving the situation.

So could be something be done to deal with this type of situation? There already is a way to handle saving settings securely, the Settings API, which was introduced in WordPress 2.7. This API handles managing settings and only allows settings to be saved by users with manage_options capability, which is normally only given to Administrators (and Super Admins when using MultiSite). The problem with it is that it doesn’t appear to be used in many plugins (that includes our plugin with a settings page, which we are looking to rectify). It would be worth looking in to how to make it so that it is more widely used going forward.

Security Journalism is in Bad Shape

You don’t have to follow IT security closely to know that it isn’t in good shape these days, with major company after company revealing that sensitive customer data has been breached. Good IT security journalism could be an important piece of shining a light on bad practices (which are abundant) and ultimately getting security where it should be. Unfortunately, what we have found is that security journalism is in as bad or worse shape than the security they cover. Take for instance The Register’s article on the situation with this plugin. It misses many important details, like the fact the plugin was being automatically updated for many and that the update would take care of much of the issue. It then follows that up with some truly bad reporting:

The vulnerability followed what was described as the “most serious” hole in five years, disclosed last November, that affected what was then estimated to be 86 per cent of WordPress websites. That cross-site scripting hole was found in the hugely-popular WP-Statistics plugin.

First off we have yet to see any impact from the vulnerability that is mentioned as being the “most serious” hole in five years, its limited impact would be something to mention several months after it was fixed in outdated installs (the current version at the time was not vunerable, which would have been worth mentioning as well). The bigger mistake is that the author of the article is conflating a vulnerability in WordPress itself with an unrelated vulnerability in the the WP-Statistics plugin, despite having also written the article they are citing about the previous vulnerability.

Posted in Bad Security, Website Hacked, WordPress Plugins | Leave a comment

Poor Security In Automattic Sponsored WordPress Plugin

A couple of weeks ago we discussed our opinion that Automattic, the company closely associated with WordPress, should bear some of the responsibility for improving the security of WordPress plugins. That came up after we bumped in to their use of WordPress plugins for the VIP service, while trying track down the developer of a plugin to let them know of a security issue. It was only days later that we came across a closer connection between Automattic and the poor security of WordPress plugin.

As part of our efforts to improve the security of WordPress plugins we have created the Plugin Vulnerabilities plugin that alerts when the currently installed version of plugins have known security vulnerabilities (as well as listing vulnerabilities that existed in installed plugins). When we add vulnerabilities to the dataset for that plugin we verify that vulnerability exists and what versions it existed in, in some instances we have found that vulnerabilities that discoverer of the vulnerability and or the developer of the plugin claim have been fixed have not actually been fixed. That is the case with two reflective cross-site scripting (XSS) vulnerabilities recently identified in the Pods plugin. While the report says that the vulnerabilities were fixed in version 2.5, we found that they still existed in that version. While looking for a way to contact the developers to let them know that issue existed and had been publicly disclosed, we noticed that footer of the website prominently displays that the project is sponsored by Automattic:

Pods Sponsored by Automattic

According to their About page, Automattic has been sponsoring development since 2012.

After a little more digging we were able to find Pods recommend method for reporting a security issue. While we got a quick response it didn’t seem like they really understood things. In our initial contact we recommended they use Firefox when confirming the vulnerabilities still exist, due to XSS filtering in other major web browsers that would protect against the example exploits of the vulnerabilities that were provided in the advisory (the XSS filtering would not necessarily protect against more advanced exploits). In response they asked how they could confirm them in Chrome for some reason. A week later two new version, 2.5.1 and, were released that based on the changelog fixed a number of bugs, but did not fix the security vulnerabilities that have been publicly available since January 12. As of today the vulnerabilities still exist in the plugin.

In reviewing the other vulnerabilities that were included in that report another thing stuck out to us, the security of Pods has actually gotten worse over time. One of the other vulnerabilities could have lead to all the of Pods data being deleted from a website if a malicious actor could get a logged in admin to visit a specified page through a cross site request forgery (CSRF) vulnerability. That vulnerability existed back to version 2.0, but as of at least the last version of 1.x series the reset function was protected from this type of vulnerability with a nonce.

Posted in WordPress Plugins | Leave a comment

Automattic’s Responsibility for the Security of WordPress Plugins

As we have continued to refocus on the security of WordPress plugins due to our work on new plugin that warns of known vulnerabilities in WordPress plugins the question of who has a responsibility for improving the security of WordPress plugins has come up. Relying on the developers of the plugins to insure they are secure doesn’t seem to be working as many of the vulnerabilities we have reviewed are things that are not the result of complex issues, so they could have been prevented with relatively basic security precautions. Since WordPress is a volunteer effort expecting that those volunteers would be responsible for the overall security of third-party software doesn’t see right. But what about the company closely connected with WordPress, Automattic? With a valuation of over billion dollars they certainly have the financial wherewithal to bear the burden of some responsibility, but in the past we would have said no since they didn’t seem to have a direct connection with plugins, but as we recently stumbled upon they are taking advantage of them for business purposes.

Recently a reflected cross-site scripting (XSS) vulnerability was discovered in the Frontend Uploader plugin. After confirming that the vulnerability existed in the most recent version we went looking for a way to contact the developer of the plugin to alert that the vulnerability existed in their plugin. While doing that we came across a page for the plugin at Automattic’s VIP, a service where you can pay starting amounts of $5,000 a month for hosting and $1,250 for support. It turns out they offer a number of the plugins from the Plugin Directory to the customers of their VIP service. They tout those plugins (as partner integration) with this:

We’ve added 200+ extra features on top of WordPress for everyone on—and just for VIPs, we’ve added the additional plugins below, which can be integrated into your sites with a single-click, so you can take advantage of powerful partner integrations and features without touching a line of code.

Their marketing materials also touts their claimed security (which hopefully has improved after the major breach they had a few years ago):

We stay awake at night, watching over your site, so you don’t have to. Our site monitoring and secure codebase ensure an impressive uptime, and our operations team is always hands-on.

Based on all of this we certainly think that Automattic has a responsibility for improving the security of WordPress plugins since they are getting benefit from them.

If they are going to live up to that responsibility they have a lot of work to do, as can be seen in this case. After the vulnerability was disclosed in a plugin they are redistributing they don’t appear to have done anything about. As far as we can tell the vulnerability was only fixed after we reported the vulnerability to the people running the Plugin Directory (since we couldn’t find a direct contact for the developers of the plugin) and them pulling the plugin pending a fix. While the plugin was gone from the Plugin Directory it was still listed on the VIP website, though we don’t know if they continued to distribute it. It doesn’t even look as if people using VIP would know that the plugin had a vulnerability fixed since the changelog makes no mention of the new version, 1.9.3, or the security fix in it (which unfortunately is an all to common problem when plugins receive security fixes).

Posted in WordPress Plugins | Leave a comment

WPScan and Sucuri Put WordPress Websites at Risk

Yesterday we discussed a situation where the WPScan project didn’t bother to notify the developer of a WordPress plugin or the Plugin Directory about a vulnerability that they knew about. Some might excuse WPScan’s responsibility to alert them based on the fact that the vulnerability was discovered by someone else and already publicly disclosed. After running in to that situation we took a closer look at the WPScan project and found something more troubling. Back in March they started discussing a backup plugin that wasn’t properly securing backup files made by it. The issue was quite serious since some of the backup files, which can contain sensitive information, made by the plugin could be easily found with just a simple Google search. In the thread no one even brings up the idea of notifying the developer of the plugin or the Plugin Directory about the issue, which would be the way to get it fixed. Instead there is some discussion in thread on how to further exploit the poor security of the plugin in the WPScan vulnerability scanner.

We are quite sure that no one ever bothered to contact the Plugin Directory about the issue because within hours of us notifying them last week the plugin was pulled from the directory pending the security being improved. Within a few days of that, security improvements were introduced to the plugin. Based on the plugin developer’s comment at the end of the thread it doesn’t sound like WPScan had informed them either.

What makes this particular troubling is that at the same time they are at least knowingly leaving websites insecure they are selling WordPress security services.

They are not the only ones selling security services involved in this. Prominently displayed on the WPScan homepage is a banner letting you know the project is sponsored by Sucuri:

WPScan is Sponsored by Sucuri

We would ask why a security company would sponsor a project that seems more interested in exploiting security issues than fixing them, but we already know that Sucuri doesn’t have much interested in websites actually being secure. We have often been hired to re-clean websites that had previously cleaned by Sucuri. What we have found in those cases is that Sucuri didn’t do basic parts of a proper cleanup, including making sure the software on the website was up to date and determining how the website was hacked, which if done would have made it less likely that the website would be hacked again.

Posted in Bad Security, Sucuri Security, WordPress Plugins | Leave a comment

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

Posted in WordPress Plugins | Leave a comment

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

Posted in Bad Security, WordPress Plugins | Leave a comment