13 Jul

ThreatPress’ Strange Claim That Plugins Are the Most Common Cause of WordPress Website Hacking

When it comes to improving web security, one of the big problems we see is that there is so much inaccurate and outright false information put out by the security industry. That among other things, leads to people spending a lot of time and money trying to protect against threats that don’t really exist. Even when real threats get mentioned we often find that claims are being made that are not supported by the cited source of the claim (assuming there even is one). That is often the case when it comes to security surrounding WordPress, including our specific focus, WordPress plugins. As a quick example that we ran across not too long ago, a WordPress focused security company named ThreatPress claimed in a post that:

Plugins are the most common cause of WordPress website hacking.

Following that link gets you to a page that makes no mention whatsoever as to the cause of WordPress websites being hacked. What makes that so strange is that what is linked to is another post on ThreatPress’ own website, which is about how many plugin and theme vulnerabilities they added to a data set they collect last year. Considering the services that company provides they should be well aware that number of vulnerabilities found in WordPress plugins wouldn’t in any way tell you how often they are the cause of WordPress website being hacked.

It is also worth noting that their data set is missing a very significant number of vulnerabilities considering they claim to have only added 200 new plugin vulnerabilities last year, while we had added over 500. That doesn’t match up with one of their employees claim that their data set “includes all known vulnerabilities”.

28 Jun

Other Data Sources on WordPress Plugin Vulnerabilities Belatedly Add Vulnerability While Falsely Claiming It Has Been Fixed

When it comes to the problems with the security industry one of the fundamental issues is the abundance of false and misleading claims about the capabilities of products and services. The breadth of that is on display in how often that occurs with our little piece of the industry, data on vulnerabilities in WordPress plugins, where among other issues you have a company falsely claiming their data set contains all known vulnerabilities despite actually not even adding the most vulnerabilities and Wordfence claiming the data they use only contains  “Confirmed/Validated” vulnerabilities. On that latter front we recently came across another example of other data sources falsely claiming that a vulnerability had been fixed, when it hadn’t. Getting that right seems like a critical element in providing this type of data, since correctly informing about unfixed vulnerabilities seems like it would the most important element. This time it involves a vulnerability that we were warning our customers for a month before the other data sources even added to their data set.

One of the things we do to make sure we provide the most complete data on vulnerabilities in WordPress plugins is to monitor for indications that a new version of a plugin includes a fix for such a vulnerability. With version 2.0.5 of the plugin WordPress Comments Import & Export, which was released on May 7, originally one of the changelog entries was “Fix the vulnerable to Remote Command Execution.”. Minutes later it was changed to “Bug fix, comment data filtered.” We looked into that and found that there was a CSV injection vulnerability that was attempted to be fixed in that version, but the fix was incomplete. We then put out a post with the details of the vulnerability on May 17. We notified the developer of the plugin that the vulnerability had not been fixed then as well. On June 6 the changelog was modified again to add “CSV Injection was fixed – reported by one of our user (Bhushan B. Patil) CVE-2018-11526”.

While the details of our post on the vulnerability are only available to our customers, other data providers could have known a fair amount about the vulnerability with just the title of our post. The final version of the changelog would have also given them a lot to go on and yet they didn’t add the vulnerability until it was disclosed by the discoverer.

When the discoverer, Bhushan B. Patil, disclosed it, they incorrectly stated it had been fixed. That isn’t an uncommon situation. Despite that, other data sources just blindly repeated that it was fixed without checking things over.

Here is ThreatPress’ entry:

The most widely used data source, the WPScan Vulnerability Database, got things even more wrong since they claim it was fixed in version 2.0.4:

Proper Warning Missing

One key difference with those data sources and ours is that they are accessible for free, so there is a tradeoff to be made when using a free data source. If the lack of checking if vulnerabilities were fixed was the only limitation with those data sources, you could mitigate that by testing out if vulnerabilities in plugins you use have actually been fixed, but that isn’t only one of the issues with them. Another is that they are missing plenty of more important vulnerabilities than the one in WordPress Comments Import & Export from their data sets. Take for example an unfixed vulnerability in the plugin KingComposer that we discovered and had disclosed on May 16. That is a vulnerability that we have seen evidence that hackers are already trying to exploit, so it would be something that you would want to be warned about, but those data sources still don’t contain that vulnerability. Since we don’t want people to be left in the dark in that type of situation we includes the details of vulnerabilities that look like they are being exploited in the free data that comes with the companion plugin for our service, so even those not using our service can be warned.

Any providers using data sources like those should be providing proper warning about the quality issues that are inherent in the data they are using. Unfortunately that isn’t the case. Some even take it further. Earlier we mentioned how Wordfence claims that the data they use on plugin vulnerabilities is “confirmed/validated”, but there data is none other than the WPScan Vulnerability Database, which as this situation shows, doesn’t do that. Lying in that way seems like it should be a serious issue, but considering that Wordfence has a long history of serious lies like that, which haven’t impacted them so far, we unfortunately don’t think it will cause them any damage.

10 May

How Free Data Sources for WordPress Plugin Vulnerabilities Compare To Us with Possibly Targeted Vulnerable Plugin

One of the reasons why security is in such bad shape despite the enormous amount of money spent on it is that there is a failed market when it comes to security products and services. In simple terms it isn’t currently possible for consumers to make well informed decisions between different products and services due to rampant falsehoods and outright lies about them as well as a lack of watchdogs to limit those or independent entities that provides accurate information needed to be able to make informed decisions. What sticks out to us is how widespread these falsehoods and outright lies are. We often see them in just the somewhat obscure area we deal in, data on vulnerabilities in WordPress plugins.

Just last week we discussed how the makers of the very popular WordPress security plugin, Wordfence Security, were lying by claiming that the data source they use is “official” and only contains “confirmed/validated” vulnerabilities. In reality neither of those claims is true, there is no official source of WordPress plugin vulnerability data and their data source doesn’t actually confirm or validate vulnerabilities before including them. What they didn’t mention nor are we aware of them disclosing elsewhere is what the data source used is, which is the WPScan Vulnerability Database. They are hardly alone in using that source and they are certainly not alone in not being upfront about using that data source, which is its own problem because we have seen people believe that multiple organizations were confirming a vulnerability when all of them were simply repeating an unconfirmed claim from that data source.

Even in an instance where a service was being upfront about using their data, they were falsely claiming that it providing better quality data than it truly does. Three months ago we discussed MainWP promoting their usage of WPScan’s data with the claim that:

The Vulnerability database updates itself real-time so you don’t miss out on any vulnerabilities.

The reality here is that something updating in real-time does not say anything about the completeness of its data, just how much time it takes for new data to propagate and WPScan’s data is far from the most complete.

The WPScan Vulnerability Database is Not Listing any Vulnerabilities in This Plugin

As we mentioned earlier today, yesterday we had a request probably from a hacker on this website for a file from the plugin Google Drive for WordPress (wp-google-drive), which contains a vulnerability that was disclosed a month ago. As we discussed at the time of disclosure, the vulnerability was incorrectly labeled as being a remote code execution (RCE) vulnerability when disclosed. The actual type of vulnerability, arbitrary file deletion vulnerability, is a type that based on past experience is not something that hackers have been very interested in, so the interest from a hacker may be due to them believing the plugin actually contains a RCE vulnerability, since those are much more likely to be exploited, at least based on past experience.

Whether something in the plugin is actually going to be exploited or not, it would seem that letting people know that this plugin has publicly disclosed unfixed vulnerability would be even more important considering there is what looks to be targeting of the plugin. If you are relying on WPScan’s data though you wouldn’t know about it. If they had any vulnerability for the plugin in their data set it should be listed between the following two plugins, but nothing is listed:

By comparison we have listed the vulnerability in our data set since April 13. Considering that the vulnerability is unfixed and was listed on a prominent general data source since shortly before that, there isn’t a good reason for WPScan’s data to not contain it. At the same time WPScan’s data is available for free for non-commercial software, so the quality may be in line with what should be expected in that instance. The problem though is that often times it is promoted like MainWP promotes it, leading people to believe they are getting access to data at the same quality level as ours, without the cost of ours.

Other Free Sources Do Better, But Still Get It Wrong

WPScan isn’t the only free accessible source of vulnerability data and others do better when it comes to this plugin.

With the companion plugin for this service we include free data on vulnerabilities that look to be being exploited. Due to noticing the request for this plugin we added the previously disclosed vulnerability to it today, along with another vulnerability we found while looking over things.

In looking at other free data sources we found they included the vulnerability, though inaccurately labeled.

The plugin WebDefender, which contains its own vulnerability data, added the vulnerability on April 16, but labeled it as “Remote CE”, which seems to indicate they didn’t actually check over the report before adding it. Two days later the data source ThreatPress added the vulnerability and also incorrectly labeled it as a “Remote Code Execution (RCE) vulnerability”. When vulnerabilities are not checked over this can lead to a number other issues, including incorrectly stating that a vulnerability has been fixed when it hasn’t, which is rather common occurrence.

The closest we found to an accurate labeling was in spreadsheet linked to from an April 16 blog post on WPCampus that labeled it as “Authenticated Arbitrary File deletion” vulnerability. We are not sure where the idea that it required being logged in to exploit it, but at least the general type is correct.

13 Oct

Not Really a WordPress Plugin Vulnerability – Week of October 13, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Directory Traversal Vulnerability in WP Smush

There recently was a report of a directory traversal vulnerability in WP Smush. If you believed the developers (who are also the developer of a security plugin) this is a vulnerability, the changelog for version 2.7.6 is:

  • Security: Fixed path traversal vulnerability. Thanks Ricardo Sánchez(@neorichi) for responsible disclosure.

The report provides a link that is supposed to confirm that it is a vulnerability, that link is to this comment in a thread on the WordPress Support Forum:

@neorichi, Just to update you, we’ve a new security release to fix the bug.

Appreciate your efforts to report this responsibly.

Cheers, Umesh

Looking at the proof of concept it seemed like something might be off about this, as it seemed that you might need a nonce to exploit the issue, but the report doesn’t explain whether a valid nonce is needed or not and if so, where it could be found:


That URL indicates that an AJAX accessible function is being accessed. Looking at version 2.7.5 that function is only accessible to those logged in, which is not noted in the report (that would make this an authenticated vulnerability at least):

add_action( 'wp_ajax_smush_get_directory_list', array( $this, 'directory_list' ) );

Looking the function being accessed, directory_list(), which is located in the file /lib/class-wp-smush-dir.php, you can see that before it checks for a valid nonce it checks to make sure the user making the request has the “manage_options” capability:

function directory_list() {
	//Check For Permission
	if ( ! current_user_can( 'manage_options' ) || ! is_user_logged_in() ) {
		wp_send_json_error( "Unauthorized" );
	//Verify nonce
	check_ajax_referer( 'smush_get_dir_list', 'list_nonce' );

Users with the “manage_options” capability would normally only be Administrators (and if others are given the capability they would normally be able to create Administrators accounts), which would normally have the ability to view the directory structure with their capabilities, so this isn’t really a vulnerability.

If you are going to claim this is a vulnerability (as the folks at ThreatPress,  WPCampus, and the WPScan Vulnerability Database have) we don’t see how it could be claimed that it is fixed as the change just restricts you to accessing directories within in the WordPress directory:

//Get the Root path for a main site or subsite
$root = realpath( $this->get_root_path() );
$dir     = isset( $_GET['dir'] ) ? ltrim( $_GET['dir'], '/' ) : null;
$postDir = strlen( $dir ) > 1 ? path_join( $root, $dir ) : $root . $dir;
$postDir = realpath( rawurldecode( $postDir ) );
//If the final path doesn't contains the root path, bail out.
if ( !$root || $postDir === false || strpos( $postDir, $root ) !== 0 ) {
	wp_send_json_error( "Unauthorized" );

Persistent Cross-Site Scripting (XSS) Vulnerability in Contact Widgets

A frequent source of false claims of vulnerabilities in WordPress plugins is a lack of understanding of the WordPress security model. WordPress has a capability “unfiltered_html” that allows users to do the equivalent of cross-site scripting (XSS), which in simply terms is just the ability to use JavaScript code. A claim of a persistent cross-site scripting (XSS) vulnerability in the plugin Contact Widgets  involved adding JavaScript code to a widget that is part of the plugin. Normally only Administrators are allowed to edit widgets, so the testing likely was done with a user who has the ability to do the equivalent of the vulnerability.

In one of the responses to the claim, one of the developers responded:

Then this is not a bug. We explicitly allow Administrators to do whatever they want in the widget via that unfiltered_html permission, just as core does with the Text widget.

Looking at the code here is what he is talking about (in the file /includes/class-contact.php):

'sanitizer'     => function( $value ) { return current_user_can( 'unfiltered_html' ) ? $value : wp_kses_post( stripslashes( $value ) ); },

Just to further confirm things were working correctly, we gave an Author level user, who doesn’t have the “unfiltered_html” capability, the ability to edit widgets by giving them the “edit_theme_options” and then tried the proof of concept. As expected the malicious input was sanitized and there was not exploitation, so there isn’t a vulnerability here at all.

18 Sep

Neither ThreatPress’ Database Nor Any Other Contains All Known WordPress Plugin Vulnerabilities

When it comes to getting data on vulnerabilities that have been in WordPress plugins that are being used on a website you have two main options. You can pay for our service and gain access to the data that comes with that or there several free sources of vulnerabilities available that can be accessed through plugins (there are others selling access to that free data and other sources that provide limited data on plugin WordPress plugin vulnerabilities as part of more general vulnerability data).

The free data is good option for a lot of people because it is free, but as the old saying goes you get what you pay for. The quality and quantity of data is lacking in comparison to what we provide, so we wouldn’t recommend them for websites that have security needs that would warrant being able to spend money on security.

A problem that we have found is that there are people unintentionally or intentionally making claims that those free sources are in fact much better than they are. That obviously is problematic for us, since people might believe that they are not getting more when paying for access to data, but it also leaves people that use those sources believing that they are being provided better data than they really are.

In May we touched on a claim that the WPScan Vulnerability Database has the “the most complete list of vulnerabilities” in WordPress plugins and in July we further confirmed that to not be accurate as we found that we had added 3 times as many vulnerabilities as that source in the month of June.

Recently we ran across someone that was has repeatedly promoted another source of data, ThreatPress. One claim being made about that source stood out:

It includes all known vulnerabilities

Based on knowing what we do and checking on how others are doing (because we want to make sure we are providing the best data possible), we can say with complete certainty that no data source contains all known vulnerabilities in WordPress plugins.

One way quick way to measure the completeness of data is to look at how many newly disclosed vulnerabilities have been added to sources recently. To do that we took a look at how many vulnerabilities disclosed so far this month have been added to the data sets of ThreatPress, WPScan Vulnerability Database, and for us. Here are the results:

  • ThreatPress: 2
  • WPScan Vulnerability Database: 3
  • Plugin Vulnerabilities: 14

You can see there is a clear difference between what you are getting with a free source versus paying for access to our data. Even the 14 vulnerabilities we have in our data isn’t all of them this month, as there are several vulnerabilities that we are still in the process of reviewing before adding to our data set.

Looking at the vulnerabilities the other two sources are missing, a couple of things stood out.

One of them is that neither of the free sources have any of the 3 vulnerabilities we have added to our data set that have not been fixed, which seem like they would be important to include.

The other is that the majority of new vulnerabilities added in our data set so far this month are also vulnerabilities that we discovered, all of which are missing from those free sources, despite them being publicly disclosed at the same time we added them to our data set.

That second issue also gets to an important point about our service; our service isn’t just about collecting data on vulnerabilities disclosed by others as those other data sources incompletely do. Among other things, we are discovering vulnerabilities and helping to get vulnerabilities we and others have discovered fixed. Recently most of the vulnerabilities we have discovered have come from our proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. Other sources are the security reviews we do of plugins selected by our customers and additional vulnerabilities we identify while reviewing reports of vulnerabilities that have been discovered by others.

23 May

How Our Data on Vulnerabilities in WordPress Plugins Compares to ThreatPress

One of things we focus on with our service is making sure we our providing the best data on WordPress plugin vulnerabilities to our customers. As there a number options out there, we look to see how they compare to make sure we are surpassing that. What we have found so far is that the other options out there really are not in the same league as what we provide (and they don’t provide the other important features that we do). The latest source we ran across seems to be a good example of that.

One of the thing we do be able to provide data on the most vulnerabilities is that we monitor for changes made to plugins that are related to security, which in addition to vulnerabilities and other security fixes can bring up changes made to security plugins. Through that we ran across a new plugin named ThreatPress and its data set of plugin vulnerabilities. A quick check showed several issues, the first being enough to disqualify this source as serious alternative to us at this time.

That issue is that the data set has very few recent vulnerabilities:

While the heading for the data listed is Disclosure Date, the dates for the first couple of entries don’t match the disclosure dates in their references, so either the dates refer to something else (maybe when they added them to their data set) or they are didn’t reference their real source for those for those listings (which seems possible as well for those two entries).

Since their dates are not clear, for comparison purposes we will assume the disclosure dates listed is the same as the month they added them. So far in May we have added 22 vulnerabilities and they added 0. Last month we added 84 (most of them being from a set of plugins we were one of three discoverers of) and they added 2. In March we added 41 and they added 4.

Quantity isn’t everything, but looking at the results most of the vulnerabilities they added are not likely to be exploited and they hadn’t added what is probably the most serious recent vulnerability. That vulnerability also hasn’t been added to other available data sources either, showing that they don’t even take the simply step of monitoring vulnerabilities that we publicly disclose. With them failing to include those, not surprisingly they are also missing the harder to find ones that we are able to spot through our fairly expansive monitoring.

There were a couple of other issues we noticed in a quick check over their data:

Inaccurate Impacted Versions

Like other data source we have seen, they don’t actually determine what the earliest version that is vulnerable while labeling as if they had. For example, for the most recent vulnerability, a reflected cross-site scripting (XSS) vulnerability in Ultimate Form Builder Lite, the listing under the Versions heading is:

Affected In <= 1.3.2
Fixed In <= 1.3.3

As with many vulnerabilities, not all versions below 1.3.3 are actually impacted. In our testing we found it only impacted versions starting with 1.2.0.

Where that type of detail is particularly important is if you are using the data as part of a hack cleanup, as from our experience they often involve websites that haven’t been updated for some time. When relying on other data source you can end up being told that there are vulnerabilities on the website that don’t actually exist in the version being used, which could mislead as to the source of the hack. We also provide an estimate of the likelihood of exploitation, which helps to focus on vulnerabilities that are likely to be the source of the hack (as many vulnerabilities have almost no chance of being exploited on the average website).

More Bug than Vulnerability

The second most recent vulnerability listed is Multiple SQL injection in AccessPress Social Icons, which we wouldn’t consider a vulnerability. If you just looked at their changes made in the version that fixes it there does appear to be a SQL injection vulnerability fixed. But if you actually look into the details, as we did at the time it was disclose you would see that the page where this occurs on is only accessible to those logged in to WordPress with the manage_options capability, which would normally only be Administrators:

add_submenu_page('aps-social', __('Social Icons','accesspress-social-icons'), __('Social Icons','accesspress-social-icons'), 'manage_options', 'aps-social', array($this, 'main_page'));

Administrators would normally be able to almost anything they want, so a SQL injection vulnerability wouldn’t provide them with any access they wouldn’t have. They also would normally be able to edit installed plugins, so they could undo any protection against this type vulnerability as well.

If you were to give a lower level user the manage_options capability they would normally be able to create a new Administrator level user with what they have access to with that capability.

If this was considered a vulnerability it should have been labeled as an authenticated SQL injection vulnerability.

With this issue there also isn’t even a possibility of cross-site request forgery (CSRF) coming in to play, as the plugin checks for a valid nonce before the potentially vulnerable code ran:

if (isset($_GET['action'], $_GET['_wpnonce'], $_GET['si_id']) &amp;&amp; wp_verify_nonce($_GET['_wpnonce'], 'aps-edit-nonce')) {
} else {