27 Jun

Pagely Downplays Serious Problems With The Handling of Security Vulnerabilities in WordPress Plugins

Security isn’t in great shape these days and that certainly applies to WordPress plugins as some recent issues we have run across have reminded us. As we see it, one of the causes of this is that real problems with security rarely get discussed. There are probably many factors at play to cause that, but one that we see is that people will criticize you if you say anything they interpret to be negative when it comes to security (the irony of that seems lost on them). That seems to lead to a lack of honesty about what is going on and instead a focus on happy talk that doesn’t resolve the problems, even though many could be fixed without much effort if there was an interest in doing that.

An example of not discussing the real problems comes up with a post we ran across from the blog of WordPress web hosting company Pagely. The post discusses the increasing issue with PHP object injection vulnerabilities in plugins, but hidden below the surface of the post is a couple of problems that writer clearly is aware of, but doesn’t disclose. The relevant section of the post is the following:

Full disclosure: I am the reporting party for some of the above vulnerabilities. One in 2016, and so far in 2017, seven. I took a weekend to see how many insecure usages of unserialize() I could find in the plugin code base and within hours had handfuls of working vulnerabilities; I stopped only so I could start triaging and notifying plugin authors regarding how to enact fixes. Many of which were appreciative for the help.

That all sounds nice, it just isn’t true in one important way and that gets to a couple of major problems with the security of WordPress plugin that people on the WordPress side of things don’t seem to be interested in dealing with.

If you look up the vulnerabilities the author is referring to you will find that only 2 of the 8 have been fixed. For the unfixed plugins it seems unlikely they are going to be fixed considering that the plugins last updates were years ago:

The position of the people running the Plugin Directory is that people shouldn’t be warned about unfixed vulnerabilities, but as these plugins show many vulnerabilities have little chance of ever being fixed. Their continued refusal to warn people of those or to update the plugins themselves, which they have the ability to do and we would be happy to help them with, means that websites are being hacked when the hack could have been prevented.

It is unclear why Pagely’s post doesn’t mention any of this, instead only saying of their interaction with developers of the plugins, “Many of which were appreciative for the help”.

The other piece to this that isn’t mentioned is that all of those unfixed plugins still remain in the Plugin Directory. According to the listings for those vulnerabilities that isn’t due to the Plugin Directory not knowing about them, “The original researcher notified WordPress Plugins team.”. There are numerous problems with how the team behind the Plugin Directory handles security issues, but we haven’t seen any interest from them to improve what they are doing. Again, that would be something we would be happy to help them with.

It would be great if going forward Pagely would be willing to be honest about was is going on and maybe help to push WordPress to start finally warning about plugins with known vulnerabilities (something we have trying to get them to for over five years).

Vulnerabilities Left Undiscovered

Something else worth highlighting from that post is this:

There are a lot of plugins out there, and a lot of vulnerabilities – I had to cut my research short just due to time constraints. If you’re a researcher interested in picking up or helping out with this issue (hunting vulns, writing PoCs and recommending patches), get in touch.

Doing that type of work takes a lot of time, unfortunately it is something that most WordPress based security companies don’t do much, if any, of. Instead far too often they seem to be focused on making up threats and then claiming they will protect against them, then doing anything toward dealing with real threats. We do a lot to find and fix vulnerabilities in plugins, we have disclosed 18 vulnerabilities this month, and we have recently started trying to be more proactive in catching vulnerabilities as they are being introduced in plugins. If we had more customers we could do more, whereas those other companies would probably spend additional money to do things that are not all that helpful to improving the security surrounding WordPress.

09 Jun

WordPress Plugin Directory’s Security Review Leads to Putting Public At More Risk

Yesterday we announced we have temporarily ended our notifications to the WordPress Plugin Directory when there are plugins with disclosed vulnerabilities in the current version of the plugin that is in the directory, until they put forward concrete plans to resolve two issues. One of those is finally warning people when they are using plugins that have been removed from the Plugin Directory for security issues. While years ago they claimed they were working on doing this, more recently they have claimed that doing so would put people at more risk. It is truly bizarre position to take just considering that many of these vulnerabilities have been publicly disclosed, so hackers would already have easy access to as much or more information than anyone has proposed including when warning webmasters of the issue. Then you have the fact that plenty of these vulnerabilities are not only known to hackers, but being actively exploited before the plugins were removed from the Plugin Directory (we know this because we have reported many of those to the Plugin Directory).

While that is really a black and white issue, when it comes to security many things are not like that. And in many cases actions do have serious unintended consequences that are not obvious. For example, we wouldn’t have though that the Plugin Directory doing a security review of a plugin after it has been removed for a security vulnerability could lead to putting the public at more risk, but that turned out to be the case as we recently found.

When it comes to suggesting how to improving the handling of security issues with WordPress plugins one of the problems we have found is that things on the WordPress side of things are very opaque. For example, we know they have the ability to release new versions of plugins with a fix when the developer doesn’t do it, but we have found no explanation of what the criteria for doing that are. It looks like the main criteria may be a vulnerability getting press coverage, as that seems to be main difference between the one vulnerability we have seen do that with since the beginning of last year and several other nearly identical vulnerabilities that were all being exploited widely. If we knew what the criteria were we could suggest a change to make sure those plugins actually get fixed. About the only thing they do provide clear information on is what is required to have an update forced out.

Another issue we can’t find any information on is the security review that is done before a plugin removed from the Plugin Directory due to a security issue is returned to it (if you are aware of where that information can be found please let us know). We know these reviews are done from looking at changes made to plugins and some things we have heard from developers, but beyond that it is a mystery.

What we do know though is that they have or cause a number of problems. Far too often we have found that plugins have returned to the Plugin Directory without the vulnerability that caused them to be removed being fixed. In some cases other security changes have been made in response to a request from the Plugin Directory, so there clearly was a review, but one that didn’t accomplish what seems like its most important goal.

The review also slows down a fixed version being released, which seems like it might be a reasonable trade-off if the reviews insured the vulnerability was fixed, but it doesn’t. In some cases where the vulnerability has actually been fixed, but the review brought up other issues that were required to be resolved before the plugin returns. In some cases though the additional issues are not significant, so people remain at risk of the most serious issue for an extended period of time.

Another issue that we see happening, though we don’t have a good idea of how often it is occurring, is that developers decide to abandon the plugin due to this review process. On the one hand if the developer isn’t willing to properly handle security of their plugin, this might not be the worst thing, though with WordPress not warning people about vulnerable plugins it does leave a less than desirable situation. But what if that actually caused public to be at more risk? Well that actually has happened.

Back in January a persistent cross-site scripting (XSS) vulnerability was disclosed in the plugin Contact Form DB, which according to wordpress.org had 500,000+ active installs at the time. That plugin saves contact form submissions submitted through various contact form plugins, including Contact Form 7. After the developers interaction with the Plugin Directory team over improving the security of the plugin they decided to no longer list it in the Plugin Directory. As we noted at the time, the developer wasn’t entirely accurate in describing the situation, as their original attempt to fix the vulnerability had not actually resolved it as the claimed (we had contacted them privately to information of that, but never heard back), so it isn’t clear how much the plugin not returning to the Plugin Directory was on the WordPress side.

Whatever the case there, one of the end results is that many people using the plugin are still using an insecure version of the plugin. As far as we can tell other providers of vulnerability data for WordPress plugins still don’t list this vulnerability in their data (which speaks to the higher quality of our data), so even if someone is taking the extra step of using some product or services, other than ours, that warns of vulnerabilities in plugins they are unlikely to know about this.

Another end result is that other plugins started to gain popularity and new plugins were introduced.

Looking the chart of downloads of the plugin Save Contact Form 7 you can see the impact of the other plugin’s removal (please note the chart counts updating existing installations as downloads as well as new installs):

There is an immediate spike after Contact Form DB was removed. There is then a big spike in late February after an update was released. A lot of those downloads are people that stuck with the plugin, as it went from having 1,000+ active install in December to 4,000+ in February to the current 10,000+.

Going back to the chart you can see that the downloads drop to 0 at the beginning of March, which we would guess was caused by the plugin being removed for a security issue. After version 2.0 was released, which was listed in the changelog as a “Security update.” we tried to figure out if there was a vulnerability fixed and spotted a fix for SQL injection vulnerability in that version.

Also worth mentioning here, according to the stats on wordpress.org even a month after 2.0 was released less than half the installs are using that version:

Version 2.0: 39.5%

When we were looking over that SQL injection vulnerability we found a much more serious issue in the relevant code, it turns out that all the contact form submissions saved by the plugin are publicly accessible. More than a month after we contact the developer about the issue we have not heard back from them and the vulnerability remains.

With the ease of exploitation that is something that we believe is more of an issue that the vulnerability that lead to Contact Form DB being removed from the Plugin Directory or what sounds like the issues that were causing the Plugin Directory team to not return it to the directory. Based on the downloads chart it is pretty clear then that the security review has led to a lot more websites using this plugin and putting many more contact form submissions at risk of disclosure.

After discovering that vulnerability we looked over similar plugins and found that another had more limited version of this. The plugin Contact Form 7 Database allows anyone logged in to WordPress to view any contact form submissions saved by that plugin. On a lot of website that isn’t much of an issue, but if account creation is widely available on website, say if it, like our website, use WooCommerce, it could be more serious. When we contacted company behind the plugin more than a month ago about the issue they responded “Our developers working to fix it”, but so far it hasn’t been fixed.

That plugin was only introduced to the Plugin Directory in the middle of March, but it already has 3,000+ active installs.

Like Save Contact Form 7, that isn’t the only vulnerability has recently been discovered in the plugin. After running across a report of a persistent cross-site scripting (XSS) vulnerability (that report used to exist here, but has been removed), we found a reflected cross-site scripting (XSS) vulnerability and cross-site request forgery (CSRF)/form submission deletion vulnerability in the plugin. Those were eventually fixed.

08 Jun

Taking a Stand Against the Continued Poor Handling of Security With WordPress

While WordPress handles security fairly well, there are plenty of problems that we have seen in the work have done that ultimately lead to this service and then in doing the work for to this service, including ones that are leading to websites being hacked that shouldn’t be and that make our work to actually get the security of plugins improved unnecessarily harder. Some of these problems are getting worse, so we have decided to stop doing work that people on the WordPress side should have been doing themselves all along until they present concretes plans to fix two of the many issues. In the short term this will leave those not using our service with worse security, but if WordPress chooses to start moving in the right direction then security can be improved from where it is now. We would then love to work with them to improve other issues, as there are lots of areas were small changes would likely lead to significant improvement.

Poor Handling of Security

One of the most glaring recent examples of the poor handling of security is a refusal so far to fix a vulnerability in WordPress that was disclosed to the security team in July 2016 and publicly disclosed a month ago. The explanation for not having fixed it in all that time is underwhelming:

“It’s a lower priority issue, but we are aware of it and it is in our queue to address,” Campbell said. He explained the unique set of conditions that would be required in order for this to be a serious vulnerability.

Even a low priority security issue shouldn’t take at least 11 months to fix.

A much longer running problem is that WordPress is refuses to warn people about plugins that have removed from the Plugin Directory that have security issues, despite some of those vulnerabilities being widely exploited even before the plugin is removed (something we are aware of because we have frequently been the ones to report those exploited vulnerabilities to the Plugin Directory). The main reason they have given for leaving the public in the dark is that it would put them at more risk, which doesn’t hold water.

One of the other reasons given by a forum moderator for that was:

The problem with this whole idea is that users start thinking about security incorrectly and that causes more problems then it thinks.

We are not sure how warning that websites are using vulnerable plugins causes thinking incorrectly about security, but there are much larger problems along those lines these days when it comes to WordPress. Much of that is due to security companies spreading false information about the security of WordPress. You might think that if that is reason enough not to warn about vulnerable plugins that are already being exploited, then it would also lead to people on the WordPress side taking a stand against such companies. That isn’t the case, instead we have seen them defending those companies or even promoting them in ways that normal users never could.

For example, there is one moderator the repeatedly has replied to comments about hacked websites with the following lines as part of their reply:

If you’re unable to clean your site(s) successfully, there are reputable organizations that can clean your sites for you. Sucuri and Wordfence are two.

While both of those companies are well known, the evidence doesn’t support them being reputable.

Just recently we found Sucuri falsely claiming that our website was hacked due to a page being titled “Hacked Website Cleanup”, which was yet another bad false positive from them, and we found them claiming one of their customers website was secure despite easy to spot malicious code that was compromising credit card information entered on it (and despite the customer telling them the comprises were happening).

For Wordfence, they really don’t seem to have a basic understanding of security, which appears to lead them to make false claims about security threats while claiming that they care more about security than people on the WordPress side. We also would not consider reputable a company that makes blanket claims that there plugin will protect websites from being hacked (which just from a technical prospective it can’t), while failing to protect against threats it should be able to.

The embrace of questionable, at best, security companies, isn’t just an issue with forum moderators. When it comes to bad security companies, of which there are many, one stands out and that is SiteLock. There reputation can be summed up in what pops up as Google’s second search suggestion when you type in their name:

The Second Suggestion is "sitelock scams"

While there are a litany of issues we have seen with them, one that stands out if are concerned about “thinking about security incorrectly “, is their falsely claiming that WordPress websites contain vulnerabilities they don’t due to them apparently lacking even a basic understanding of how WordPress handles security (and even after it being pointed out that they were giving out bad information).

Despite that, not only is the WordPress security team giving them access to non-public sensitive security information they don’t need (the security team has time to do that, but not to fix low priority vulnerabilities) but they are allowed to sponsor and speak at various WordCamps.

Getting back to the forum moderators they have taken actions to prevent webmasters from knowing they are using vulnerable plugins while at the same time allowing unfounded security claims about plugins to remain on the forum.

We Have Stopped Notifying WordPress of Vulnerabilities in the Current Versions of Plugins

When it comes to low hanging issues with the security of WordPress plugins one of them is making sure that plugins with known vulnerabilities in the current version are not in the Plugin Directory. What we came across over five years ago was that this wasn’t happening, we tried at the time to get people on the WordPress side of things to start monitoring for that situation and taking action, but it wasn’t successful. We have at times done the monitoring for them and out of that eventually came this service. Based on the periods of time when we were not doing that for them, we are about the only ones that have, so without us reporting those the plugins often remain in the Plugin Directory indefinitely.

Seeing as this isn’t actually our responsibility to do, we feel that suspending our doing that is reasonable action to take until WordPress make concrete plans to improve two areas that impact the focus of our service and our work.

Concrete Plans Needed For Fixing Two Serious Issues

While there are a lot of areas that need fixing, we have decided that there are two areas that really are in need of fixing that directly tie in to with our service, though for one of them making the change would likely be bad for our business. Once WordPress has provided concrete plans to fix these we will start reporting the vulnerabilities to them again.

The first is there needs to be concrete plan for finally warning when plugins that have been removed from the Plugin Directory and providing at least a general reason why it was removed.

It has now been nearly five years since we suggested doing that on the Ideas section of the WordPress website and it wasn’t long after that the head of the Plugin Directory said that it was being worked on. Not only has that not happened, but the position changed that it can’t be done. Despite that the idea is still marked as “Good idea! We’re working on it”, which clearly isn’t the case. One reason that might be is that since it marked as being worked on it doesn’t getting listed on the front page of the Ideas section under Most Popular Ideas, where it otherwise would be the third most popular idea (it has 69 votes):

The continued refusal to properly handle this situation is utterly baffling to us, and from reading others comments, it seems that really isn’t something that anyone outside of the WordPress team is in agreement with them on. Their inability grasp something that is so black and white, makes trying to have a reasonable discussion about problems with their handling of security where there is more gray area seem not worth trying (we will be discussing one example of that  in an upcoming post).

The second is that the moderation of the WordPress Support Forum needs a complete overhaul and likely would need a wholesale removal of the current moderators.

The problems with the forum moderation tie in with the first issue, as back in February the head of Plugin Directory, who seems to be the one spearheading leaving people in the dark about removed vulnerable plugins, shutdown a thread discussing the issue as being “non-productive”. Just based on their conflict of interest they should not have been shutting that down, but to make matters worse before they did that they allowed themselves to get the last word in thread. When you can’t even have a conversation about something that is leading to websites being unnecessarily hacked, it points to huge problem with handling security.

It was also the poor forum moderation that was the last straw with the handling of security as while we were trying to get a vulnerability fixed a moderator got in the way and falsely accused of disclosing a vulnerability. False accusations and interrupting actual discussions are all too common from the moderators.

This issue doesn’t just impact us though. One of the things we do to keep track of vulnerabilities in WordPress plugins is monitor the Support Forum for security related threads. What we have seen is that usually the only response is from a moderator, either providing a canned response that isn’t relevant to the poster’s issue or providing incorrect information. It isn’t hard to see why that is since anyone that has actual knowledge in the area is likely to quickly run in to a moderator that doesn’t have a good grasp of security and seems to be more interested in lording over the forum then helping anyone (we wish that was hyperbole). There are plenty of posts where we could provide some insights around original poster’s issue, but it just isn’t worth the grief and false accusations that come from the moderators, we doubt we are alone in that considering that no one else is doing that.

Some of what we have seen moderators do is about as bizarre as the refusal to warn about removed plugins, as one example, one time while someone (or someones) were disappearing replies from us they deleted another person’s reply that simply thanked us. That being despite the claim that:

Forum topics will only be edited or deleted if they represent a valid legal, security, or safety concern.

What would be a legal, security, or safety concern about saying thank you?

How Does This Change Impact You

If You Already Use Our Service

For our customers we hope it doesn’t impact you much.

If you were to install a plugin that previously would have been removed due to us reporting a security issue in it, you will know get notified of the issue the next time the service’s companion plugin does a check of your installed plugins.

We already included a listing of vulnerabilities that had been in a plugin in a new tab when looking in to the details of a plugin on the “Add New” plugins page:

With the next release of the plugin we are adding a new alert on the main details page:

We looked into adding them to more broad based listing pages but that introduced some issues, which made that less than ideal, so we are not adding that at this time.

If you are using a plugin that has vulnerability in the current version we are, as we always have been, there to consult with you on what the best way of dealing with that it. It might be that you can safely ignore the vulnerability (if say it was in plugin functionality you don’t use). In most cases we can come up with a workaround until the vulnerability is properly fixed (we also try to work with developers to get the vulnerabilities in their plugins fixed). In other cases a plugin might be so insecure that the best option is just to find another plugin to use.

If You Don’t Use Our Service

You are likely going to have more issues since you are going to have an increased chance of using plugins that have security issues, including the possibility of ones that are already being exploited, as we are the only ones monitoring for that type thing, much less notifying the Plugin Directory about that. That is unless someone else takes over the monitoring and reporting that we do, but considering that never happened in time periods where we haven’t been doing that prior to starting this service, it is unlikely to happen. We will continue including vulnerabilities we see exploited in the free data that comes with companion plugin for the service, which you really should already have installed even if you are not using our service.

If you are concerned about this we would recommend you get the word out that WordPress should come up with concrete plans to fix the issues mentioned earlier in the post, so that we can go back to reporting unfixed vulnerabilities to them.

In the meantime signing up for our service will give you even better protection than you would have if we were reporting these vulnerabilities to WordPress, because while that would prevent you being able to install known vulnerable plugins, if you were already using you would still be in the dark (if they actually start warning people you would be warned without needing our service). When using our service you also have access support from a company that actual understand the vulnerabilities (other security companies don’t even understand enough to be able to check if a plugin really has a vulnerability), allow us to help developers make their plugins more secure, and the ability to suggest/vote for plugins to have security reviews done by us.

17 Feb

WordPress Shutdowns Discussion of Their Refusal to Warn About Unfixed Vulnerable Plugins

Since 2012 we have been trying to get WordPress to start warning webmasters when their websites are using plugins that have been removed from the Plugin Directory due to security issues (and notify people in general that they are using plugins that have been removed from it). In the past WordPress’ position was that they were working on implementing this, but as of the last year the position has changed that they can’t do this because it would cause people to be “MORE at risk“. Not only does this not make sense, as we will come back to in a moment, but they don’t want to even honestly discuss the issue. For example, last July they even deleted a reply of ours on the Support forum pointing out that the handling of vulnerable plugins was not in as good shape as they were portraying it.

With that background it probably shouldn’t be surprising to see what happened to a recent thread on the wordpress.org Support Forum, which we previously mentioned, that was discussing the lack of notification when plugins are removed from the Plugin Directory. The head of the Plugin Directory decided to close that thread due to it being “non-productive”. It seemed plenty productive to us, as people were discussing better ways to handle things. The closing seems to us to be part of a continued lack of professionalism on part of people on the WordPress side, which really isn’t acceptable considering the widespread and high profile use of the software. Seeing as the person doing the closing is intimately involved in the issue being discussed, it doesn’t seem like they should be making the call to close the thread.

Before they closed it they got to have the last word, which makes the closing even more problematic. By closing the thread after that it doesn’t allow for others to try to help them understand that WordPress’ position on this is not only misguided, but is leading to websites being hacked that should not have been. Since we can’t reply in the now closed thread, we wanted to explain again why the position they are taking is so bad.

Here was there explanation on why they think it is a bad idea to warn people:

Since we remove plugins for many reasons, the minority of which being security related, we do not disclose the reason why any one particular plugin was removed. Our quite serious and valid concern is that if we were to disclose that a specific version was at risk without providing a fix, we would put people at a greater risk. In addition, by removing the plugin, we put pressure on the developers to address the situation promptly.

As we have discussed in more detail previously there a number of problems with that.

It starts with the fact that many vulnerabilities have already been disclosed publicly, so the bad guys are already aware of them. WordPress disclosing that the plugin is vulnerable provides less information than attackers would already have available to them. While that might cause more interest from attackers, it would also allows websites using the plugins to take action, say removing the plugin.

Then you have the fact that plenty of plugins are removed after a vulnerability is already being exploited (this something we know because we are frequently the ones that spot the exploitation and report the vulnerabilities to them). If WordPress were notifying people of the vulnerable plugin in this situation they could actually take action, while right now they are left open to being exploited. It is this fact that makes us wonder at times if there might not be a more nefarious reason for not warning people (the company closely associated with WordPress, Automattic, has a security service, VaultPress, for example).

Another problem with this idea is something the people running the Plugin Directory are aware of, which is that some vulnerable plugins are never fixed. One of the reasons we know they are aware of this is they are keeping track of how long a plugin is removed, as this part of their comment shows:

I promise you this: We ALWAYS contact the developers and do our best to make it clear what was required to have the plugin restored as quickly as possible. The average plugin is restored within a week.

Another reason we know that they know this is because it is clear that some vulnerable plugins are never going to be fixed. While most vulnerable plugins are vulnerable due to a coding mistake, there have been some plugins that are intentionally malicious. Take for instance a group of plugins we discussed back in October, where someone had copied existing plugins and submitted them to plugin directory with malicious code added to them. The developer would have no reason to release a new versions that removes the vulnerable code, as having that in the plugins was their only reason for creating them. Those plugins were also an example of another issue, even if vulnerabilities are never publicly disclosed, hackers can figure out that they existed and exploit them.

The threat that vulnerabilities pose varies widely, with many vulnerabilities having almost no chance of being exploited on the average website, so what matters the most in terms of unfixed vulnerabilities is if vulnerabilities that are being exploited or are likely to be exploited ever get fixed and how long it takes for that to happen. Two fairly recent examples show that relying on plugins being fixed by the developer is not taking care of those situations.

Take a vulnerability in the plugin Delete All Comments, which was discovered due to being the source of a hacked website. That plugin had 30,000+ active installs according to wordpress.org at the time it was removed in late November or early December, as of today it has not been fixed (it isn’t clear if the vulnerability was intentionally introduced or a coding mistake).

Back in July we spotted a vulnerability being exploited in the plugin Form Lightbox, which had 10,000+ active installs. We were not the only ones that had, as it was removed before we got around to notifying the Plugin Directory. That plugin had not been updated since 2013, so the chances of it being updated seemed low at the time, and in fact it still hasn’t been fixed.

WordPress does have another option available to them if they truly wanted to protect people, but don’t want to warn people about unfixed vulnerabilities. They can fix the plugins themselves, they even have the ability force websites to update to the new version. They have done that on very limited occasions. Like much of their handling of security, what the criteria for them doing that are not clear. That would also require more work than simply alerting people to vulnerable plugins, but since they don’t want to do that, it seems like what they should be doing if they truly were interested in keeping people safe. If they become interested in expanding when they do that, we would be happy to help.

Protecting Yourself in The Meantime

Seeing as we are often the ones that report to the Plugin Directory that a plugin has a vulnerability, whether something we discovered or something that was disclosed by someone else, but not reported to them, using our service will get you alerted to most of the vulnerabilities they are likely aware of. You also are provided with an estimate of how likely the vulnerability is to be exploited and we are available to help you make the best decision on what to do if the vulnerability in the plugin has yet to be fixed (maybe you can ignore the vulnerability or maybe we can provide you with a workaround until a proper fix is released by the developer).

Because we don’t want people to be hacked, in the companion plugin for our service we include data on vulnerabilities in plugins we see hackers targeting, so you would have been long ago warned if you were using any of the plugins with vulnerabilities we previously mentioned in this post.

With our service you also get suggest/vote for plugins to receive security reviews by us, so you have better assurance that plugins you use are properly secured.

15 Dec

When a Security Company Does the Right Thing and The WordPress Plugin Directory Drops the Ball

Due to how bad the security industry is we rarely have the ability to point to a situation where the a security company has done the right thing, but today we have one to discuss.

Yesterday, we discussed how security companies rarely do one of the three basic components of a proper hack cleanup, which is to try to determine how the website was hacked. As we mentioned in that post, in instances where that isn’t done we are frequently brought in to re-clean the websites after they get hacked again. The problem of not determining how the websites are hacked doesn’t always just impact that website, if the vulnerability exploited exists in the current version of software on the website then spotting an early exploitation has the possibility of limiting the amount of additional websites that get hacked due to it. That possibility occurred with an arbitrary file upload vulnerability that exists in the WordPress plugin Delete All Comments. On November 20 the security company NinTechNet was looking into a hacked website and found the website was hacked due to that vulnerability. It wasn’t all that hard to spot with the combination of the logging and the code in the plugin, but since so many security companies don’t even try to determine how the websites they are cleaning up have  been hacked, something like that can easily get missed.

The vulnerable code was introduced in version 2.0, which was the first release put out by a new committer and that lead someone that mentioned the vulnerability to us, to believe this might have been intentional. To us it also looks like something that could have happened when someone writes code without having a good grasp of the security implications of what they wrote.

After NinTechNet spotted this they did the following:

The author was informed on November 20th but did not respond. We contacted the WordPress plugin department and the plugin was removed from the repository the same day.

On Saturday they publicly disclosed the vulnerability. Subsequent to that we added it to the service’s data and added it to the free data that comes with the service’s companion plugin on Monday, so even those not using the service yet could have gotten notified of the issue (if you haven’t installed the plugin, now would be a good time to do that).

Looking at the logging from our websites and the third-party data we monitor we don’t see any evidence of wide scale attempt to exploit this until Monday. So between when NinTechNet came across this and that there was a chance for the WordPress Plugin Directory to mitigate the threat from this when the developer didn’t.

The easier thing they could do is to start warning people when they are using vulnerable plugins that have been removed from the Plugin Directory, but they are refusing to do that on the basis that it puts people at more risk. As we discussed before that doesn’t make much sense as hackers can still figure out that the vulnerabilities exist even if they keep quiet about it.

The other option would be for them to put out a new secured version of the plugin, which they have the ability to do. They even have the ability to have the update to that version of the plugin happen automatically, in the same way that minor WordPress updates now occur automatically (and in the same way all plugin updates can happen with our Automatic Plugin Updates plugin). Like a lot of security related items involving the Plugin Directory, the process for deciding to release a secured version is rather opaque. In one instance when we tried to raise the issue over the lack of this happening on the wordpress.org Support Forum our post was deleted without explanation and the plugin being discussed was never fixed. If they decide to improve the situation we would love to help with it.

Instead they did neither, leaving everyone using the plugin vulnerable.

Until WordPress gets better about this you can help protect your website for free by installing the service’s companion plugin and installing one of our other plugins that lists plugin you are using plugins that have been removed from the Plugin Directory. For those with the budget you can sign up for our service, where you get data on all plugin vulnerabilities, not just ones that are already being exploited, and you also have the ability to suggest and vote for plugins to have a security review done by us, which could help catch more security vulnerabilities in plugins before they have a chance to be exploited by hackers.

06 Sep

Yet Another Very Vulnerable Plugin Returned to The WordPress Plugin Directory Without Actually Being Fixed

When it comes making sure that vulnerabilities in WordPress plugins get fixed we play important role in making that happen, but we are having to play an outsized role because others are not doing their part, which has once again lead to websites remaining vulnerable to being hacked for much longer than they should have been.

One of things that we do to provide the best data on vulnerabilities in WordPress plugins to our customers is that we monitor our websites and some outside data sources for evidence that hackers are targeting plugins. In many case the evidence doesn’t itself give any indication of what the vulnerability the hacker is targeting, just that the hacker is looking for usage of the plugin by requesting a .css or .js files in the plugin’s directory. From there we try to determine if the hackers is targeting a previously known vulnerability or there is a vulnerability that exists in the current version that hacker could be targeting. Through that work we have found numerous vulnerabilities included many that it looks like hackers have known and been exploiting for months and sometimes longer. What we found fairly troubling about this is that we look to be the only security company doing, even though at least one other would certainly like you to think they are.

That brings us to our recent discovery of a persistent cross-site scripting (XSS) vulnerability in the WP-Piwik plugin. While combing through data from one of the outside data sources we monitor, we came across the possibility that a hacker had been targeting the plugin back in January. In looking over the plugin for the kind of vulnerability that hackers might exploit (many types of vulnerabilities are unlikely to be targeted by them), we noticed that anyone could change the plugin’s settings. The potential damage that could be done using that depends on what impact the plugin’s settings can have on the website. In this case, the settings could be changed to load JavaScript on the website’s page and that in turn could be used to serve malware on them. This isn’t a hypothetical issue as in February of last year, this type of vulnerability was exploited on a large scale to serve malware on websites using the Fancybox for WordPress plugin.

Once we had found the vulnerability we quickly notified the developer of the details of the issue, suggested they may want to request to have the plugin automatically updated after being fixed, and let them know that if needed any help in dealing with it, to get back to us. Two weeks went by without any response or the vulnerability being fixed. At that point we disclosed the vulnerability, added it to the data that comes with our service’s companion plugin (so that even those that don’t use the service would get alerted), and notified the Plugin Directory of the issue.

A short time later the plugin was removed from the Plugin Directory, which protected those not already using the plugin from being exposed to the issue. Those already using the plugin were left in the dark since WordPress continues to refuse to alert them in such a situation.

Two days later the plugin returned the Plugin Directory with a new version, 1.0.10, that was supposed to fixed the vulnerability, but didn’t. As those that follow our blog would already know, the WordPress’ failure to properly check over plugin’s before returning them to the directory has been an ongoing issue. In some cases you could excuse it to some extent because it would easy enough to think the vulnerability was fixed, like one situation where the code to fix the vulnerability had been added, but was one line below where it needed to be to function properly. In this case the new code was not what you would have expected to fix this, so thorough checking should have been done, but it doesn’t look like it was.

The attempted fix involved adding an additional check before saving the settings. In the function that checks if a settings change is include in the request before those changes can be applied, isConfigSubmitted(), an additional check is done by calling a new function isOptionsPage(). The function isConfigSubmitted() in 1.0.9:

private function isConfigSubmitted() { 
    return isset ( $_POST ) && isset ( $_POST ['wp-piwik'] ); 

The function isConfigSubmitted() in 1.0.10:

private function isConfigSubmitted() { 
    return self::isOptionsPage() && isset ( $_POST ) && isset ( $_POST ['wp-piwik'] ); 

The isOptionsPage() function is intended to check “if current page is WP-Piwik’s option page” by comparing two values:

public static function isOptionsPage() { 
    require_once(ABSPATH . 'wp-admin/includes/screen.php'); 
    $screen = get_current_screen(); 
    return $screen == self::$optionsPageId; 

When we tried our proof of concept (included in our post about the vulnerability) we found that this check didn’t stop the exploitation of the vulnerability. The reason for that is that two values being compared are empty and therefore the same.

We notified the developer of the issue along with a suggestion on how to properly fix the issue, they responded shortly afterward and two days later version 1.0.11 was released, which fixed the issue.

The fixed involved using another new check in the isConfigSubmitted() function by calling the isValidOptionsPost() function:

public static function isConfigSubmitted() { 
    return isset ( $_POST ) && isset ( $_POST ['wp-piwik'] ) && self::isValidOptionsPost(); 

The function isValidOptionsPost() checks to make sure that request is coming from someone who should be able to make changes to the settings, by checking current_user_can( ‘manage_options’ ), and that they intended to make the changes, by checking check_admin_referer( ‘wp-piwik_settings’ ), to prevent against cross-site request forgery (CSRF):

public static function isValidOptionsPost() { 
    return is_admin() && check_admin_referer( 'wp-piwik_settings' ) && current_user_can( 'manage_options' ) ; 

WordPress Needs to Improve

The developer could have improved the situation by responding quicker and getting back to us the first time we contacted them so we could have worked together to come up with a proper fix instead of requiring two releases to make that happen. But since developers are not likely to running into situation like this very often, trying to improve things by focusing on them seems to be difficult. Instead the people behind WordPress who deal with this type of issue on an ongoing basis seem to be the better are to focus to improving the situation. What exactly needs to be done isn’t clear because their handling of vulnerable plugins is rather opaque (making it less opaque could be starting point for fixing not only this, but other issues with the process). Maybe there needs to additional checking done before returning a plugin or maybe there needs to be a better understanding of how to checks thing over by the people already doing that. Whatever the case, we would be happy to help them, since getting these vulnerabilities fixed as quickly as possible is our goal.

17 Aug

WordPress Doesn’t Fix Severe Vulnerability in Plugin And Doesn’t Want To Have An Honest Discussion About the Issue

Recently we have been having an issue where someone (or someones) that has the ability to edit and delete post on WordPress’ support forum had been doing those things to some of our posts on their support forum. Last week discussed on such instance where that look liked an attempt to cover up the fact that WordPress has an ongoing problem where plugins they know contain a vulnerability that have been removed from the Plugin Directory due to that, then return to it without the vulnerability being fixed. Over at our main blog we discussed that it appears that whomever is doing it doesn’t want the public to know what is going, as in another instance they also deleted a reply to a post of ours that just thankedus for the information we provided, which if it remained, would have made it obvious that a post from us had existed and had been deleted. While preparing to write this post about the issue of WordPress’ handling a vulnerability in a plugin that appears to have been abandoned, we noticed that another such instance of a deletion that looks like an attempt to cover up yet another piece of WordPress’ current poor handling of vulnerabilities in plugins.

On July 17 we saw requests for a .css file from the plugin Form Lightbox across our websites. That is usually an indication that a hacker is probing for usage of the plugin before trying to exploit a vulnerability in it. Seeing as the requests hit all of our websites, that pointed to there probably being a large campaign to exploit something in the plugin. After noticing the request we started trying to figure out if there was a vulnerability so that we could add it to our data and see what we could do about getting it fixed. We quickly found an option update vulnerability in the plugin, which would allow anyone to change WordPress’ options (settings). One possible way that could be exploited is to turn on user registration and set it so that new users had the Administrator role, giving the attacker the ability to do almost anything on the website. Later in the day the plugin was removed from the Plugin Directory, so at least one other person had noticed the issue and notified the Plugin Directory before we had done so.

On July 20 a post was started on the support forum for WordPress, Plugin disappears from repo as vulnerability is revealed?. The original post was later edited, but from a cached copy here is how it read (the bolded portions were later removed by someone else with the ability to do that):

Is there any rules about triaging security vulnerabilities in plugins?

I was a fan of Form Lightbox {DEAD LINK}, a simple plugin that let you embed a form in a lightbox.

According to Google’s cache, it was still available on 16/7, 2 days before this was published:

https:// www.pluginvulnerabilities.com/2016/07/18/option-update-vulnerability-in-form-lightbox/

There’s a giant security hole in the plugin. I’ve had 4 sites exploited using it. A simple google search reveals a number of others that have been bitten.

If WordPress.org pull the plugin (in line with the disclosure practices of pluginvulnerabilities.com) , and the author fails to patch it, and make it available again, can someone else step up, take it over and issue a patch?

Otherwise, those affected are left high and dry (until they find out how their sites are being pwned, by other means).

The “WordPress.org Tech Dude” responded:

If WordPress.org pull the plugin, and the author fails to patch it, and make it available again, can someone else step up, take it over and issue a patch?

If we pull the plugin for security reasons, then the author usually patches it. If it’s severe enough, we may patch it ourselves after an author does not respond. This is handled on a case by case basis.

After noticing the thread through our monitoring of the support forum for vulnerability related issues, we saw that there were a number of problems with that reply, which we address in a reply that was deleted some time later:

Seeing as we are the people that are reporting many of the vulnerabilities to the Plugin Directory that cause plugins to be pulled, we can say that the reality is that plenty of those plugins never get fixed. In other cases they are not fixed in a timely manner. Also, in some cases you guys put the plugin back in the Plugin Directory even though the vulnerabilities have not actually been fixed, including a recent case where it looks like a hacker had been exploiting a plugin prior to it being removed from the Plugin Directory.

In the case of the plugin mentioned here, a security issue doesn’t get much more severe than this. Not only does the plugin have an easily exploitable vulnerability, but it appears that a hacker is already exploiting it. That is how we became aware of the issue in the first place.

As mentioned in the post cited above, the plugin was removed before our post was released, so the post’s release had nothing to do with the plugin being removed.

If you used our Plugin Vulnerabilities plugin you would have been warned about this vulnerability a couple of days ago, since we include data on vulnerabilities in plugins that have hacking attempts against them in the free data included with that plugin.

There was never any reply to our reply, so it seems that no one from the WordPress side wanted to dispute anything we had said in it. They then could have taken it as wake up call that things need to be improved (something we would happy to help them with). Instead at some point later our post was completed deleted without any notification to us that it in some way violated any policy on the forum. What has happened with the plugin since then, shows that, not surprisingly, trying to cover up things in this way doesn’t actually deal with the issue.

If you go to the plugin’s page on the Plugin Directory now you will see that it is still removed (the message mentioning that it has been removed in the screenshot was added to the page by the Plugin Vulnerabilities Chrome extension):


That doesn’t always mean that nothing has been done, as from what we have seen from checking on what is happening with other plugins with vulnerabilities is that there can sometimes be a significant delay between the developer submitting a new version to the underlying the Subversion repository and the plugin returning to the Plugin Directory (probably due to some review of the fix needing to occur first). In this case though, the most recent change to the plugin remains one from three years ago:


As we mentioned in our reply in that post, “In the case of the plugin mentioned here, a security issue doesn’t get much more severe than this.”, so if WordPress is going to patch severe vulnerabilities when the plugin’s author this seem to be one where that should have happened. That means that for the 10,000+ websites using the plugin (according to wordpress.org, as of the time the vulnerability started being exploited) are left without a secured version to update to. We don’t think that WordPress necessarily should be expected to fix any vulnerabilities in plugins, but what they should at least do is notify those using plugins that they are vulnerable. That is something that they could have done long ago, but they continue to refuse to do it on the basis that it would put websites at risk, which doesn’t make much sense in case like this, where a hacker is already exploiting the vulnerability on a large scale and others are able to easily identify an exploitable vulnerability in the plugin.

16 Aug

WordPress Keeping The Public In The Dark About Plugins They Know Are Vulnerable

One of the key pieces of advice for keeping your WordPress website secure is to keep your plugins up to date, since that prevents the possibility of the website from being exploited through a security vulnerability that has been fixed in a newer version of the plugin. There is a limitation to that though, that it only protects you from vulnerabilities that the developer has fixed. So what happens if a vulnerability is discovered in a plugin available in the Plugin Directory and it doesn’t get fixed by the developer? Once the Plugin Directory is notified of the vulnerability the plugin is removed pending a fix, unless the vulnerability is really minor. That protects anyone who is not yet using the plugin, since they won’t be able to install it through normal means, but what about those who already have it installed? For them nothing happens. That is something that has concerned us for years.

As part of our effort to improve the situation, four years ago we put a suggestion up on the Ideas section of the wordpress.org website suggesting that webmasters should be alerted when they are using a plugin that has been removed from the Plugin Directory. Not to long after that idea was marked as “Good idea! We’re working on it”.

Around the same the “Lead Plugin Wrangler” at WordPress explained that a solution was being worked on:

FWIW, we’re working on a solution. Part of the problem is we’ll close a plugin for many reasons:

* Guideline violations
* By request
* Security
* Licensing

And then of course there are subsets to these, like would you care about an alert if I told you a plugin was closed because it has affiliate links on the repository page? It doesn’t impact the user as much as all that. So we have to sort out how best to alert the right times, and then we have to figure out the best way to alert without spreading FUD.

We’ve actually started a step one on the backend, to allow the admins who moderate a better way of seeing what’s closed and what isn’t. Next up, a way for us to tag WHY a plugin was closed. It’s being worked on though 🙂

Four years later that still hasn’t happened. Two months ago the same person explained why it hasn’t happened:

We cannot provide this service at this time.

IF an exploit exists and we publicize that fact without a patch, we put you MORE at risk.

If an exploit exists, hackers will be targeting the vulnerability en-mass.

That’s exactly the issue. If we make it known there is an exploit, the hackers attack everyone :/

If we don’t tell anyone, then hackers who DO know will attack, but they would have anyway.

We will get in to why this is position is misguided at best in a second, but first it is worth mentioning that this isn’t a new stance. Back in February of 2012, our plugin No Longer in Directory, which lists installed plugins that have been removed from the Plugin Directory, was first rejected for inclusion in the Plugin Directory due to plugin’s description emphasizing that plugins can be removed the Plugin Directory due to security issues (which they felt was “alarmist and counter-productive”). Their message read in part:

We do not release details where possible of security issues before a fix is available. Given what you do I am sure you know this is the correct behaviour.

At the time we were flabbergasted by that, not only because they wrong, but they thought that it was obviously the right position.

Here are some of the reasons that this position is so misguided:

The Details Are Often Are Already Public

What makes hiding the fact that a plugin has a vulnerability seems so obviously misguided is that in many instances (maybe most of them) the details of the vulnerability have already been publicly disclosed. The people running the Plugin Directory are well aware of that fact just based on how often we notify them of public disclosures of vulnerabilities that are in the current version of plugins in the Plugin Directory. Hackers are already likely to know about those public disclosures, so letting people with the plugin installed know of them as well shouldn’t do much to increase the hacker’s knowledge. By comparison the average webmaster of a website using them is unlikely to know about those disclosures, so you are greatly increasing the chances that they can do something about it by notifying them, while not increasing the chances of exploitation by hacker by very much.

It Can Be Incredibly Easy To Figure Out Where a Vulnerability Exists

But what about a situation where the vulnerability hasn’t been publicly disclosed? The claim by WordPress is that “If we don’t tell anyone, then hackers who DO know will attack, but they would have anyway.” It doesn’t seem to be a good idea to us to keep quiet about vulnerabilities so that only some hackers can exploit your website, instead of making you aware of the issue so that you could remove the plugin and prevent anyone from hacking it.

What make this more problematic is that from recent experience we have found that it can be very easy to find an exploitable vulnerability by just knowing that other people are trying to exploit a plugin. Starting in early May we started getting requests on our website that seemed to be people looking for usage of plugins for which there were not known to have vulnerabilities. In all but two instance so far we were able to quickly find security vulnerabilities that are the kind that hacker would try to exploit. In one of the instances where we didn’t find a vulnerability that a hacker was would try to exploit looks like the hackers might have been trying to target a vulnerability that wouldn’t normally be exploitable and in the other the code was so insecure that we couldn’t narrow down where to look (but we did find two vulnerabilities that were less likely to be exploited).

In many of the cases we able to find these vulnerabilities in a matter of minutes. If we can do that you can be sure that people that are actually trying to hack website could do that as well.

Vulnerabilities Are Not Always Fixed in A Timely Manner, If At All

It would be one thing if WordPress withheld their knowledge of vulnerabilities for several days while a fix for the vulnerability was being put together. But as they are well aware it can be months before a developer gets around to fixing a vulnerability. For example, the plugin SEO Redirection, which has 60,000+ active installs according to wordpress.org received a fix for a vulnerability that was disclosed at the end of March in the middle of June (that plugin was then removed from the Plugin Directory again, but then returned without it being fixed). The developer didn’t even have to come up with fix since the disclosure include a proposed fix, which they used. In another case we looked at last year it took two months for a vulnerability in a plugin with 200,000+ active installs to be fixed despite requiring less than a line of code to fix.

In other cases vulnerabilities that hackers are known to be exploiting are never fixed, for example the plugin Plugin: Newsletter has an arbitrary file viewing vulnerability that was disclosed in May of 2012 that was never fixed and we continue to see attempts to exploit it. So when the WordPress folks say they won’t release details of vulnerabilities until they are fixed they are in fact saying is that they are fine with the possibility of keeping the public in the dark forever about the vulnerability.

12 Aug

WordPress Tries to Sweep Plugin Security Issue Under the Rug Instead of Fixing It

Recently we have been finding that someone on the WordPress team has been deleting and editing some of our post on their support forum and because they don’t want others to know that, in one instance they even deleted someone else’s post that simply thanked us for one of our posts. While it has been rather troubling in general, one other instance that stuck out to us in the most recent purge, was a case where they removed a single sentence from a post, that sentence was “(including when the people running the Plugin Directory have failed to notice that)”, which was in reference to the fact that we often find that vulnerabilities that are claimed to have been fixed have not actually been fixed. The linked post, from the end of March, discussed the fact that plugins that had been removed from the Plugin Directory due to security issues were returning without the vulnerabilities actually being fixed.

While it would be close to impossible to insure that all of the plugins in the Plugin Directory are free of vulnerabilities, making sure that  plugins that you are aware have had a vulnerability are not restored before they are actually fixed shouldn’t be, since it could be prevented by simply testing out to make sure the vulnerability has been fixed before restoring the plugin.

Unfortunately since March the issue has continued to happen. At the end of June we discussed another example involving a situation where we spotted what looked to be a hacker probing for the usage of the BePro Listings plugin (likely due to them being aware of a vulnerability in the plugin and looking for websites to exploit it on) and we then identified a vulnerability that hackers were likely to exploit in the plugin (as well as another fairly serious vulnerability). After contacting the developer and getting no response we notified the Plugin Directory and the plugin was removed. The plugin subsequently returned to the Plugin Directory without actually being fixed. It was only after we got in touch with the developer again that we were able, after several back and forths, to get them to finally fix it.

Just this week we spotted another instance of this happening, which also highlights the difficulty that there can sometimes be in getting developers to fix vulnerabilities in their plugins. This time it involves a persistent cross-site scripting (XSS) vulnerability that was publicly disclosed back in December of 2014 in the plugin SEO Redirection, a plugin with 60,000+ active install installs according to wordpress.org. The advisory seems to indicate that the discoverer had notified the developer at the time. A support forum post from over a year ago also notified the developer, but at the time the developer claimed the vulnerability didn’t exist:

I tested the plugin and displayed to me the same message, but there is no XSS in the plugin, ignore this message, I will try to change the parameters name or the tag name to stop this message from being appeared.

We then ran across the advisory earlier this year and added the vulnerability to our data set. At the time the plugin was removed from the Plugin Directory, due to a  SQL injection vulnerability that was in the plugin at the time. After the plugin came back in to the directory without the persistent XSS vulnerability fixed we notified the Plugin Directory of its existence and the plugin was removed a week later at the end of June. Earlier this week the plugin returned to the Plugin Directory, at that point tested it out again to make sure the vulnerability was gone and found that it wasn’t. There was a security related change in version 3.7, but it does not look like it was attempt to fix this and we can’t even tell if the change was related to a vulnerability.

It seems to us it would be a better use of the WordPress’ team members time to make sure that vulnerabilities in plugins are being fixed before restoring them to the Plugin Directory instead of trying to cover up the fact that they are not doing this. Until they get more serious about security you can protect yourself by using our service, so that you get alerted if a vulnerability is in the plugins you use, even in cases where the WordPress team misses them still existing.

01 Aug

Yet More WordPress Plugins With Apparent Zero-Day Vulnerabilities Go Unnoticed By Security Companies

One of the things we do to provide our customers with the best data possible on vulnerabilities that impact the WordPress plugins they use, is monitoring our websites for hacking attempts. For the first few months of the service we were seeing attempts to hack vulnerabilities already included in our data and very old vulnerabilities that we didn’t yet have in our data. Starting at the beginning of May we started seeing what looks to be requests from hackers probing for usage of plugins that we could not find any public disclosure of a vulnerability or any indication in the changelog that a vulnerability that hackers might be interested had existed and the been fixed in the plugin. When that occurs we quickly try to find if there is vulnerability that exists in the current version of the plugin that hackers would be interested in. In most cases we are able to find something that if hackers are not already exploiting, then they would exploit if they were to become aware of it (by comparison many vulnerabilities discovered in plugins are ones that are very unlikely to be exploited on the average website).

Seeing as we often find those vulnerabilities in a matter of minutes, those vulnerabilities are a good reminder that the security of WordPress plugins is not in great shape at this point. While some developers are quick to respond with a new version of the plugin that fixes the vulnerability, all to often fixes take weeks and in many cases the plugins have yet to be fixed. All of that is contrary what you might hear from people closely connected to WordPress.

The other thing that we have found troubling about this is that in most case we appear to be the only ones spotting the interest of hackers in these plugins and the vulnerabilities they contain. When this started happening in May, we expected the opposite, that we would be only one of many spotting these and we were interested in seeing how our response time would compare. You would certainly expect that to be the case based on how certain companies promote their services, Wordfence being one example we discussed previously.

By the middle of June as we kept spotting more vulnerabilities this way we got interested in seeing if we could gather more data than we could from just get from our websites, to see if we could catch more of these vulnerabilities and improve the speed at which we catch them. We found several websites with just such data and we quickly found more vulnerabilities. It also lead us to be more concerned about the state of WordPress plugin security, seeing as unlike the previous vulnerabilities where the explanation of why we were spotting these vulnerabilities and others were not, could have just been of our quick response to them. With many of the vulnerabilities we have found through this third-party data, that couldn’t be the explanation, since hackers seem to have starting to exploit them long ago. The first vulnerability we discovered this way involved a request from more than a year before.

As we continue to review more of that data we continue to find more such cases, last week that lead us to finding arbitrary file upload vulnerabilities (the most likely to be exploited common type of vulnerability) in three plugins, where hackers made request for the plugins in June of last year, July of last year, and February respectively. While we hope that we have made big dent in finding such vulnerabilities, we really have no way of knowing how many more may be out there.