14 Apr

Plugin Using WPScan Vulnerability Database Data Doesn’t Warn When Using Unfixed Vulnerable Plugins

While we think that our service provides the best data on vulnerabilities in WordPress plugins, for many websites paying for a service to warn about the use of vulnerable plugins is probably not in the cards. You can always use the companion plugin for our service, which includes data on vulnerabilities in plugins that are being targeted by hackers. But what if you are looking for more broad based vulnerability data? That is where data from the WPScan Vulnerability Database can be good alternative, since there is no cost for access to their data (though some services actually charge for accessing that data). It is important to note that their data has some serious quality issues, including it not warning about vulnerabilities that are included our plugin’s data despite that being for vulnerabilities that are being exploited and the data being freely accessible (if you use a plugin or service that uses their data you will want to combine it with our plugin to protect you from this situation).

There are a number of plugins that provide access to that data, but as we found yesterday while preparing a post about another problem with WPScan’s data, not all of those plugins are equal and in the case of one them it is not providing important warnings.

While looking to show an example of one of them incorrectly warning about a vulnerability due to WPScan’s data indicating that a plugin was vulnerable when it wasn’t, we found that one of them, Vulnerable Plugin Checker, wasn’t providing a warning. We then tried to figure out what was going on and found the plugin will not provide any warning that a plugin is vulnerable if the vulnerability hasn’t been fixed. That is pretty serious issue since the most important use of this type of data is to warn when a vulnerability hasn’t been fixed, since if it has been fixed, simply keeping your plugins up to date will protect you even if you are not aware of the vulnerability.

To show what the cause is, let’s take a look at part of the code that adds a warning to a plugins listing on the Installed Plugins page, which is handled in part by the function admin_head(). The code checks to see if the plugin is known to be vulnerable with this line:

if ( isset( $plugin['is_known_vulnerable'] ) &&  'true' == $plugin['is_known_vulnerable'] ) {

The determination if it is vulnerable is handled with the following check in the function get_cached_plugin_vulnerabilities() (a substantially similar one is in the function get_fresh_plugin_vulnerabilities()):

// if plugin fix is greater than current version, assume it could be vulnerable
$plugin['is_known_vulnerable'] = 'false';
if ( version_compare( $vulnerability['fixed_in'], $plugin['Version'] ) > 0 ) {			
	$plugin['is_known_vulnerable'] = 'true';

For a plugin that hasn’t been fixed the value of $vulnerability[‘fixed_in’] in that will be null, so the plugin is considered to not be known to be vulnerable. Because the plugin is not considered to be vulnerable, no warning will be provided.

The end result of that if someone is relying on this plugin they would not be warned if, for example, they were using the latest version of Delete All Comments, despite a serious vulnerability in that, which was discovered by a security company after it was used to exploit a website:

We have notified the developer of the plugin through the WordPress Support Forum of the issue, so hopefully for those relying on the plugin it will get fixed quickly. If you are using another plugin or service that relies on WPScan’s data it would be a good idea to check if they are properly handling this type of situation and otherwise properly handling the use of WPScan’s data (in one other case we found a security company was misusing their data on vulnerabilities in WordPress and making false claims about WordPress websites being insecure).

Non-Independent Reviews

For a plugin that seems to have such a fundamental problem, taking a quick glance at its page on the Plugin Directory it might be surprising to see that it has received only five stars reviews:

While it is possible that independent reviewers might not have noticed this issue, in this case it looks like most of the reviews come from problematic sources. One comes from the developer of the plugin, another one comes from what looks to be their brother, and another one comes from account that looks like it was created just to post the review, which often is an indication that it isn’t an independent review. This seems like a good reason for those connected with a plugin to not be reviewing their own plugins, as it provides a skewed view of the plugin (would they ever give the plugin a poor review?).

13 Apr

WPScan Vulnerability Database Incorrectly Identifying Some BestWebSoft Plugins as Being Vulnerable

Earlier today we disclosed a reflected cross-site scripting (XSS) vulnerability we had found in numerous plugins by BestWebSoft after another security company that had independently found the same vulnerability disclosed it (the developer of the plugins was aware of it before either of us, but hadn’t fixed it in most of their plugins).

If we hadn’t already known about the vulnerability and prepared the data on the vulnerable plugins we would have had a lot of work to do today as the vulnerability impacts 53 plugins. The most time consuming part of preparing that data is determining what versions are vulnerable, but doing that insures that our customers are only notified if they are using a vulnerable version. While this vulnerability is unlikely to be exploited, for vulnerabilities that are likely to exploited determining the vulnerable versions is also important for those using the data while cleaning up a hacked website as it is possible that a website might be using a version that is older than the version identified as being vulnerable but is not vulnerable due to vulnerabilities not always existing in all older version (in a couple of cases last year vulnerabilities being exploited on a wide scale only existed in a single version of the plugins).

For those relying on another service or plugin to warn them of vulnerabilities in WordPress plugins they use, the underlying source of the data is likely from the WPScan Vulnerability Database and for those people they are likely to fair number of them being warned that they are using a vulnerable version of one of BestWebSoft’s plugins when they are not. The cause of that is that according to WPScan’s data none of the plugins have been fixed despite the fact that 13 of them have been fixed and were fixed before the disclosure. Take for instance the most popular fixed plugin, Google Sitemap by BestWebSoft, which has 90,000+ active installs according to wordpress.org. The vulnerability was fixed in that plugin two weeks ago.

Here is how it would look if WPScan’s data indicates a vulnerability was fixed:

And here is how their listing for this vulnerability currently looks:

Here is how it looks for an end user using one of the plugin’s that uses their data if they have the current version of Google Sitemap by BestWebSoft installed, despite it not being vulnerable:

The Downsides of Using WPScan’s Data

While we think that WPScan’s data is a good option for a lot of people because it is available for free, it does come with significant downsides that anyone using should know about. This also includes odd omissions of vulnerabilitieslisting false vulnerabilities in their data and listing vulnerabilities that haven’t been fixed as being fixed. Not only are we not aware of anyone using their data including notice of those issues, but some plugins and services that use the data don’t disclose is as the source of their data so even if someone was aware of the issues with their data, they wouldn’t know it impacts them. Also problematic are services that actually charge for access to the data, because if you are paying for WordPress plugin vulnerability data then you should be getting better quality data than this.

20 Mar

False Vulnerability Report: Store XSS Vulnerability in WP Markdown Editor

As part of our cataloging the vulnerabilities in WordPress plugins for our service we come across false reports of vulnerabilities from time to time. So that others don’t spend their time looking over these as well, we post our findings on them. The data on these false reports is also included in our service’s data.

When it comes to false reports of vulnerabilities in WordPress plugins some of them don’t set off any red-flags until you start to look closely at them. Others, like a recent report claiming there was persistent cross-site scripting (XSS) in the plugin WP Markdown Editor set off multiple red-flags with the just a quick glance, though they still require being fully checked as some reports of actual vulnerabilities end up being quite of poor quality.

The first red-flag in the report was that there was no code or other detailed information provided; instead the report consisted entirely of a small amount of text and three screenshots. If the person behind the report hadn’t looked at the underlying code, they could have missed important information that would have let them understand if a vulnerability actually existed or not.

That issue is particularly acute in this case because the screenshots showed saving JavaScript code on the page for adding a new post to WordPress and being saved. Normally both Editor and Administrator-level users are allowed to do just that due to having the unfiltered_html capability, so the action being taken is also a red-flag that this might be false.

To test out the vulnerability we first tried taking the actions show in the report logged in as an Author-level user. We entered the code on a new post as suggested in the report and clicked the “Toggle Preview” button and the JavaScript ran, which really isn’t a vulnerability (as we will come back to in a bit). Since this is supposed to be a persistent XSS vulnerability this JavaScript code needs to persist when saving the post, but it didn’t. It didn’t even get displayed when previewing the post normally.

We then tried everything again but with an Administrator-level user. Unlike the previous instance the JavaScript remained when saving the post. That would indicate that the plugin was not actually permitting persistent XSS, as Administrator-level users, unlike Author-level users, should be able to do that and the reporter likely did their testing using a user with the unfiltered_html capability.

As confirmation of that we tried things again with an Editor-level user that had the unfiltered_html capability removed and the JavaScript was not saved.

So there isn’t a persistent XSS vulnerability, but what about the JavaScript code running for the Author-level user when clicking the “Toggle Preview” button. Seeing as the user would be taking the actions to cause that it would probably be classified as self XSS, which isn’t a vulnerability, but a social engineering attack because you would need to trick someone into doing that. Is that a concern? Not really, since the same exact thing could be done by getting them to enter JavaScript code into their web browser’s console.

WPScan Spreads a False Report

While we actually test out vulnerabilities before adding them to our data, so we avoid including false reports like this, other data sources clearly do not. Take the WPScan Vulnerability Database, which is the true source of WordPress plugin vulnerability data for almost any service or plugin other than ours that provides that type of data,  it has this false vulnerability in their data set:

That is despite those major red flags that the vulnerability likely didn’t exist.

Why Was The Plugin Removed From the Plugin Directory?

If you visiting the page for the plugin in the Plugin Directory now you will get this as the plugin has been removed:

As of a couple of weeks ago it was there. Was it removed due to the Plugin Directory incorrectly believing there was vulnerability in it? Maybe, but it could also be something else. Unfortunately the people behind the Plugin Directory continue to keep people in the dark about removed plugins.

06 Feb

If You Used Our Service You Would Already Know About the Security Vulnerability That Has Been in Contact Form DB

Back in 2012, years before we started this service we noticed a couple of big problems with how security issues in WordPress plugins were being handled. The first one was that there were many vulnerabilities that existed in the current versions of plugins that had been publicly disclosed, but the plugin remained available in the Plugin Directory. The second was that when a vulnerability in a plugin was reported to the Plugin Directory the plugin was removed from it, protecting any websites not already using the plugin from the vulnerability, but websites already using it were not given any notice of the vulnerability, leaving them vulnerable.

In the present the first problem would likely still largely exist if wasn’t for us making sure that developers and the Plugin Directory are notified when unfixed vulnerabilities are disclosed. The second problem still exists despite it being indicated years ago that a solution would be forth coming, a more recent explanation of why that hasn’t happened doesn’t make sense.

The second problem has recently been a topic of discussion in relation to what has happened to the plugin Contact Form DB, which wordpress.org had recently reported as having 500,000+ active installs. Several weeks ago a persistent cross-site scripting (XSS) vulnerability that existed in the plugin was disclosed. Shortly after that the plugin was removed from the Plugin Directory. At this time the plugin remains out of it, due to the Plugin Directory insisting on further security improvements. While that is the case people have been wondering where it went and then discussing the fact that the current handling of this type of situation leaves people left with no information when something like this happens.

Considering that we suggested letting people have at least a general idea of what is going on years ago, we obviously think giving everyone information on what is going on is a good idea. In the meantime if you are using our service you would already know what is going on, something that would seem to be useful to someone like one of the commenters there, whose comment in part reads:

That would also enable existing users to know that there was a vulnerability and choose to disable or knowingly risk it. As it is now, my agency has hundreds of sites using this plugin and we had no idea there was an issue with it.

One of the ways we keep track of vulnerabilities in WordPress plugins is to monitor the WordPress Support Forums, something we started doing after belated becoming aware of a plugin with intentionally malicious code shortly after we started the service. Through that we became aware of the vulnerability on January 13 and added it to our data on the same day.

Another thing we do as part our service, which others providing vulnerability data on WordPress plugins don’t do, is that we test out each vulnerability, so when the developer released a new version, 2.10.29, that was supposed to fix this, we tested it out. We found that it didn’t fix it, we then updated our data so our customers would know that they were still vulnerable. We also notified the developer of the issue and where in the code the vulnerability still remained (as well as a suggestion for a better fix). A newer version has been submitted to the Plugin Directory that does resolve this, but it currently isn’t available through the normal update mechanism.

For vulnerabilities that haven’t been fixed we are always available to work with our customers to make a determination as to what to do in the meantime. Maybe it is something you can safely ignore, maybe it is something that disabling, but not removing won’t resolve, or maybe we can provide with a workaround (as we could have in this situation).

Other Providers Still Don’t List This Vulnerability

So what if you are relying on another provider of vulnerability data in plugins? You wouldn’t know about this vulnerability. If you get your vulnerability data from another plugin or service it likely uses data from the WPScan Vulnerability Database (the use of their data is not always disclosed) and the vulnerability still isn’t listed in that. That is also true for the plugin CWIS Antivirus Scanner, which uses its own data.

At this point the people behind those could have known about the vulnerability even without doing the extensive monitoring we do, to provide our customers with the best data, as we listed it in our latest monthly post on what was new with the service along with the rest of the vulnerabilities we added last month. That’s a reminder of the lower quality of the data you are going to get if you get your plugin vulnerability data from someone other than us.

07 Dec

WPScan Vulnerability Database’s Data Can Leave You Unaware That You Are Still Vulnerable

Recently we looked at two instances where the WPScan Vulnerability Database only included some of sets of vulnerable plugins that we had disclosed, leaving those relying on their data unaware that they were using plugins with known vulnerabilities in the current versions. One set of vulnerabilities were easily exploitable and the other set involved plugins that it looked like hackers were already targeting, so the omissions were pretty serious. We still don’t understand how that happened, seeing as it is much easier for the WPScan Vulnerability Database to add new vulnerabilities than it for us since they don’t review the vulnerabilities before adding them. Their lack of reviewing vulnerabilities causes its own issues, as we found in two cases where they were claiming that vulnerabilities were fixed when they were not. If it were not for us, those vulnerabilities would still be in the plugins at this point, which is a reminder of the critical role we play in the security of WordPress ecosystem.

Bad Report = Bad Fix

Recently a report of a vulnerability in the very popular NextGEN Gallery plugin, which has 1+ million active installs according to wordpress.org, was released. We continue to be unsure of what vulnerability the report was actually trying to refer to since in only a few sentences it seems to be referring to an authenticated local file inclusion (LFI), authenticated arbitrary file viewing, or authenticated remote code execution (RCE) vulnerability. The WPScan Vulnerability Database list the vulnerability as being an authenticated local file inclusion vulnerability:

But in our testing we couldn’t find where that or an authenticated arbitrary file viewing vulnerability would have existed in the relevant code. Whether either of those vulnerabilities existed it seems to us that the vulnerability definitely existed, the authenticated remote code execution vulnerability, was the most serious, since it would allow you to do the equivalent of both other vulnerabilities.

In the version that reporter of the vulnerability and the WPScan Vulnerability Database reported it to be fixed, it wasn’t. The developer had made a change in that version that would have been relevant for either a local file inclusion or arbitrary file viewing vulnerability (though the code that already existed had same impact on the possibility of an arbitrary file viewing vulnerability). After we notified the developer, a change was made to try fix the actual vulnerability, but the first attempt included a security check that was easily bypassed. After notifying them of that and suggesting a more secure way to accomplish that, the vulnerability was finally fixed in version 2.1.60.

Fixed and Fixed Again

The second vulnerability also involves a bit of confusion. While the report of a vulnerability in the Check Email plugin labels the vulnerability as a cross-site scripting (XSS) vulnerability, parts of the report claimed the issue was caused by a cross-site request forgery (CSRF) issue. In version 0.5 of the plugin, protection against CSRF was put in place for the sending of test emails, but this protection didn’t do anything for the XSS issue because that can occur without any attempt to send a test email. After noticing the issue we contacted the developer and after one additional release, 0.5.1, that didn’t fix the issue, we were able to work with them to get a proper fix to the issue put in place with version 0.5.2.

As of November 15 the WPScan Vulnerability Database listed the vulnerability as being fixed in version 0.5:

A week later it was supposed to have been fixed 0.5.1:

You Need To Double Check Their Data

If you are using data from the WPScan Vulnerability Database and you actually want to be sure that vulnerabilities in plugins you use have been fixed you will need to test out any relevant vulnerabilities yourself, or you could sign up for our service, where we actually do the testing when adding vulnerabilities to our data (there are a number of other advantages that come with our data).

11 Oct

Another Example of the WPScan Vulnerability Database’s Spotty Inclusion of Recently Disclosed Vulnerabilites

When it comes to data on vulnerabilites in WordPress plugins, at this time you really only have two choices our data or the data from the WPScan Vulnerability Database. We think that WPScan’s data is a good option for a lot of websites since it can had for free, but for websites that can afford to spend money on the security of the websites using their data comes with some significant limitations. A couple of weeks ago we looked at an example of one of those, we found that with related arbitrary file upload vulnerabilites in four plugins we had disclosed they had only included one of them. Considering that type of vulnerability is likely to be exploited and that two of the plugins they didn’t include listings for had not been fixed, so doing the basic security of keeping your plugins up to date would not have protected you, that was a pretty big issue. By comparison we had included all of them in our data at the time we disclosed them.

The source of our discovery of those vulnerabilites also is a big difference between the data sources, our data isn’t just compilation of third-party data on vulnerabilites like WPScan’s. One of the other sources of vulnerabilites in our data set is vulnerabilities we find based on monitoring what plugins hackers are targeting. Sometimes it is obvious from that what vulnerability they are targeting, but in other cases we only see that them probing for usage of the plugin, but not what they would target if it existed. The four vulnerabilites mentioned earlier came from that.

Through that monitoring we recently saw a hacker probing for usage of six plugins. Unlike most cases where we are pretty sure we found the vulnerability the hacker would be targeting, this time we are not sure if the vulnerabilities we found are the ones being targeted. Last Monday we disclosed vulnerabilites in five of the plugins (and mentioned they may be other security issues). For the sixth plugin the vulnerability we spotted while trying to figure out what might have been the connection between the plugins had already been disclosed more that two years, but must never have been reported the wordpress.org Plugin Directory as the plugin still remained there until the time we notified the people running it.

The next day the WPScan Vulnerability Database added the persistent cross-site scripting (XSS) vulnerability in WordPress Appointment Schedule Booking System to their data (incorrectly labeling it as being an authenticated vulnerability though). The other four vulnerabilities that we disclosed at the same time have not been added (the previously disclosed vulnerability was already in their data).

In the previous instance we couldn’t see anything that might explain why the vulnerability they did add was included and the others were not. That is also the case in this instance. The vulnerability they included didn’t have the most active installs, it was tied for second with 400+, while another had 1,000+. It also wasn’t the type of vulnerability as there were two other persistent XSS vulnerabilites disclosed. It wasn’t a combination of the active installs and type, as the other 400+ active installs vulnerability was also had the same type of vulnerability.

While missing vulnerabilites is a pretty significant issue, as long as WordPress chooses to leave the public in the dark about plugins they know contain vulnerabilites in their most recent version even if you don’t get notified about all of the vulnerabilites being disclosed, using the WPScan data will provide additional protection over keeping your plugins up to date. But if you want the best data when it comes to that signing up for our service provides you that. We also include vulnerabilites that we see being exploited in the companion plugin for the service, so installing that even if you have yet to sign up for the service, will provide protection over and above keeping your plugins up to date. Security plugins on the other hand will provide you little in the way of protection as can be seen in our recent tests of them against vulnerabilites in plugins.

03 Oct

Without Us Vulnerable Plugins Would Remain in the WordPress.org Plugin Directory

A couple of the important things we do when it comes to vulnerabilities in WordPress plugins came together the other day, providing an example of what happens if we were not doing it. One of the ways we keep track of what plugin vulnerabilities are out there is to monitor our websites apparent hacker activity. Through that we came across a request for the readme.txt for several plugins, including the plugin Gallery Objects, that we didn’t have installed. That type of request is usually an indication that hackers are probing for usage of the plugins before attempting to exploit something in it.

While trying to figure out what the vulnerability the hacker might be targeting in the plugins, we thought there might be some connection between the vulnerabilities in all of them. After spotting what looked to be a SQL injection vulnerabilities in several of them, we took a look at the others to see if they might contain them as well. When we got to Gallery Objects we easily found one. After we had done that, we did a check to see if there were any other vulnerabilities that had previously been disclosed in the plugin and found that the same SQL injection vulnerability we found had already been disclosed in July of 2014, which was before we started collecting data for our service (so our data for that time period is more limited than it is for newer vulnerabilities).

When we come across a disclosed vulnerability that exists in the current version plugin we usually notify the developer (unless they appear to be long gone) and if they don’t respond or we didn’t notify them first, we notify the wordpress.org Plugin Directory. At that point, unless it is really minor vulnerability, they will pull the plugin pending a fix. If anyone else had been doing the same at the time this vulnerability was disclosed the plugin shouldn’t currently be in the Plugin Directory, but it still was there as of the other day:


After we notified the Plugin Directory the plugin was removed within half an hour, further confirming that no one had previously notified them. It isn’t that others didn’t know, for example the WPScan Vulnerability has had the vulnerability in their data for over year:


But they must have never bothered to notify the Plugin Directory, which would have lead to the plugin being being removed and protected anyone who would have otherwise installed that known vulnerable plugin (we give them credit for having the vulnerability in their data before us, though).

26 Sep

Omission of Very Exploitable Vulnerabilities From the WPScan Vulnerability Database Is a Reminder of Its Limitations

If you are looking to be warned about vulnerabilities in the WordPress plugins used on your website there are really only two sources of data available to do that as far as we are aware of. There is the data for our service and the data from the WPScan Vulnerability Database (there are some others out there, but they haven’t been updated in quite some time). While we obviously think highly of our data, we think that for a lot of people that the WPScan data is a good option since it can be accessed for free through several plugins available in the Plugin Directory. That free price though hints at the fact that their data has some important limitations in comparison to the data that is provided when using our service.

Because the vulnerabilities are not actually verified before be included in their data, as we do, that leads to situations where vulnerabilities that don’t actually are exist are included and more problematically leads to vulnerabilities being listed as already being fixed when they still exist in the current version of the plugin. Because we actually test out each vulnerability we are able to catch situation where vulnerabilities have not been fixed and often able to help get those quickly resolved, which limits the impact that false claim that vulnerabilities have been fixed on those relying on WPScan’s data.

Another limitation with their data is that even though it is easier for vulnerabilities to be added to their data since they don’t need to be verified first, we have seen that they are missing a fair amount of recently disclosed vulnerabilities. That can be seen in something we noticed with a set of four vulnerabilities we disclosed a week ago.

Two months ago while looking into the possibility of a vulnerability elsewhere in the code of the plugin N-Media Post Front-end Form we found an arbitrary file upload vulnerability in it. In looking at the other plugins from the same developer we found that there was similar code with the same type of vulnerability in WooCommerce Extra FieldsN-Media Website Contact Form with File Upload, and Front end file upload and manager Plugin. One of those, WooCommerce Extra Fields, was fixed a couple weeks after we notified the developer of the issue, but the other three were not fixed. After waiting two months for them to be fixed we disclosed the vulnerabilities, notified the Plugin Directory of the issue, and they have been removed from that pending a fix (one of those, Front end file upload and manager Plugin, has now been fixed and returned).

Seeing as arbitrary file upload vulnerabilities are probably the most targeted type of vulnerability and we frequently see them being the source of successful hacking attempts, you would want the data source you use to warn you about them. As of today WPScan Vulnerability Database only contains a listing for the vulnerability in N-Media Website Contact Form with File Upload, which was added to their data two days after we disclosed it. We can’t think of a reason why that one would be the only included. One possibility we considered and rule out was that maybe it was the most popular of the plugins, but it only recently had 1,000+ active install according to wordpress.org, while two others had 2,000+ active installs (the final one had only 90+).

Since we discovered the vulnerabilities we have had them in our data since we disclosed them. (We don’t currently include vulnerabilities we have discovered, but not disclosed due to the fact that while it limits our customers knowledge of potential threats against them, it would possible for malicious actors to sign up for the service and use the same data for malicious purposes.)

If you understand the limitations of WPScan Vulnerability Database it can be a good option as the other free option is to not be warned at all. Where things can be more problematic is if a service provider (a web host or security company) is using their data without disclosing the source and not disclosing the limitations inherent in their data.

Their data can sometimes be degraded when used by providers, as we recently found that web security SiteLock appears to be using its data from that and was ignoring some of the data included, leading them to falsely claim that vulnerabilities existed in the WordPress version installed on some websites.

Also, in the case of Shield WordPress Security, they are actually trying to get people to sign up for a paid service on the basis of it checking WPScan’s data, despite the fact that it can be easily access for free through other plugins (incidentally while that plugin is marketed as being the “most powerful” and “most advanced” it has fail to stop exploitation of a vulnerability in a plugin in either of our recent tests of security plugins).

11 Jul

Wordfence Is Either Providing Bad Information Or Taking Credit For Vulnerabilities Someone Else Discovered

From what we have seen recently, the Wordfence company has a habit of saying things that are not true, from claiming a WordPress plugin vulnerability had been fixed when it wasn’t, to claiming their Real-Time Threat Defense Feed has “unmatched access to information about how hackers compromise sites” while not detecting vulnerabilities being exploited in the current version of plugins that we easily detected, to claiming that their firewall provides blanket protection against persistent cross-site scripting (XSS) while not actually catching real world exploit attempts. With noticing all that in just the past few weeks the latest situation isn’t all that surprising, but is worth noting, since at best they are putting out bad information and at worst they are trying to credit for discovering vulnerabilities in a plugin that had already been fixed when they claimed to have contacted the developer about them.

On July 6 Wordfence posted about three vulnerabilities they had discovered in the WP Maintenance Mode. They claimed that version 2.0.7 “included fixes for 3 security vulnerabilities”, and the title of the post indicates that the vulnerabilities existed in “2.0.6 and older”. The post also states that they “notified the plugin author last week”, which would mean that they notified the developer on June 26 at the earliest.

When we went to look at the vulnerabilities to add them to our data, we quickly found the changes related to fixing the authenticated remote code execution (RCE) vulnerability in version 2.0.7. We couldn’t find any changes that look related to the other two vulnerabilities. But based on the description we were pretty sure where the issue would have been, but found that the proper security was in place to protect against them 2.0.6. When we went and looked back to older versions we found that vulnerabilities had in fact existed from version 2.0.0 to 2.0.3 and had then been fixed in version 2.0.4.

Version 2.0.4 was release on June 17, which is more than a week before Wordfence claims to have contacted the developer about the vulnerabilities.

The changelog for 2.0.7 credits Wordfence for two items:

  • reset_settings _wpnonce check (thanks # Wordfence)
  • modules > google analytics code sanitization (thanks @ Wordfence)

The first is something that Wordfence didn’t bring up in their post and the other refers to the authenticated remote code execution vulnerability. The changelog for 2.0.4 doesn’t mention Wordfence or even mention anything that appears to be related to the vulnerabilities fixed.

In the best case, Wordfence actually reported all of the vulnerabilities and then incorrectly listed what version was vulnerable and when they contacted the developer. That wouldn’t be a huge issue, but with so much of security being about trust and considering their track record we would probably recommend avoiding them based on that track record alone. It would much more of an issue if they are taking credit for vulnerabilities discovered by someone else.

We Always Verify Data Before Adding It To Our Service

When we add vulnerabilities to the data set for our service we test it out first so that we can insure the vulnerability existed (there are more than a few false reports of vulnerabilities), that it has actually been fixed (many times we find that a vulnerability has not been fixed, despite a claim that it has), so that we can let you know what version are vulnerable, and so that we can accurately label the vulnerability. Other similar data sources don’t do any testing, so for example in this case, if you use a plugin or service that uses data from WPScan vulnerability database you are incorrectly told that those two vulnerabilities existed up to version 2.0.6 and were fixed in 2.0.7 (you also are not told which other versions were vulnerable):


While that has a limited impact in a case where the vulnerability has been fixed, since most people are probably just concerned about being protected now that the vulnerability has been exposed, but in other cases they will falsely claim that a vulnerability has been fixed when it hasn’t.

27 May

Web Host Pantheon Spreading Inaccurate Information About WordPress Plugin Vulnerabilities

One of the things we do to keep track of what vulnerabilities are out there in WordPress plugins, so that we can provide our customers the best data, is to monitor the WordPress forums for postings related to them. One thing that has lead us to notice is that the quality of postings isn’t always great, take for example a claim of a vulnerability in the plugin Advanced Custom Fields. That claim lead to three separate posts in a matter of a week all mentioning the same issue, instead of those people just adding to the existing post (that isn’t an uncommon occurrence).

In this case the claimed vulnerability is something that we don’t consider a vulnerability. The claimed issue is that the plugin allows cross-site scripting (XSS), but since the only people that would be able to access the functionality needed to do it are Editor and Administrator level users that would normally have the unfiltered_html capability, they are specifically given the ability to use the equivalent of cross-site scripting (XSS) already. It would probably be more accurate to describe the issue as a bug. The people running the Plugin Directory agreed with us that it wasn’t a vulnerability.

It was perfectly reasonable for the posters to have brought this up since your average WordPress user isn’t going to have the expertise to review the report as we can (and had already done when it was released in the beginning of May). What seems to be more of an issue is that others that should be better informed would be passing this claim along without doing the proper checking. One of those was the web host Pantheon, which had notified one of their customers and then the customer had then been one of the posters.

On the homepage of Pantheon’s website they claim to have Enterprise-Grade Security


and they state that they have a

Relentless, around the clock commitment to website security

So it isn’t too much to think they could handle reviewing such a report before passing it along to their customers.

Instead they look to have outsourced doing that to the WPSCan Vulnerability Database.

From the post:

They link to this website: https://wpvulndb.com/vulnerabilities/8481

With a little more checking we found that as part of their WordPress Launch Check tool they take data from the WPScan Vulnerability Database to warn about plugin vulnerabilities. The problem with doing that is that data source is known to not always contain the most accurate information, due to a lack of verification.

Just this week we looked at a completely false report of a vulnerability, which they include in their data. And a couple weeks before that we noticed another false report that they listed and listed as being fixed, but also being a potential false positive that “Needs further investigation.”. How they can know it was fixed, but not be sure if it actually existed in the first place is odd.

It isn’t just including false report of vulnerabilities, they also list vulnerabilities as being fixed in a certain version when the vulnerability has yet to be fixed.

If Pantheon wants to continue to use that data they really should be manually reviewing it before passing it along to customer or at least warn them that is isn’t necessarily accurate.

In the meantime if you are looking for higher quality Plugin vulnerability data, you can always sign up for our service. We verify each vulnerability we add to our data set, so you don’t run into those issues and we help to make sure that outstanding vulnerabilities actually get fixed instead of listing them as being fixed when they are not.