Login

Not Really a WordPress Plugin Vulnerability

13 Sep 2019

Not Really a WordPress Plugin Vulnerability, Week of September 13

In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release 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. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Cross-Site Scripting in Sell Downloads

The report of claimed cross-site scripting vulnerability in the plugin Sell Downloads doesn’t make sense, since if you follow the proof of concept steps provided, the third one can’t be done. Working around that, we found that the report was false as the reporter didn’t understand that those with the unfiltered_html capability are allowed to place the equivalent of cross-site scripting (XSS) in to comments on posts, which is what they were claiming is a vulnerability, so there isn’t an issue here and even if you considered that an issue, it would be with WordPress, not the plugin. [Read more]

10 Sep 2019

SiteLock is Making the WPScan Vulnerability Database’s Low Quality Data Worse

One of the things that we believe leads to the poor state of security of WordPress, as well more generally, is the amount of inaccurate and outright false information spread by those involved in security. That also creates unnecessary hassle for others. When it comes to our area of focus, the security of WordPress plugins that is a constant issue. While we properly vet claimed vulnerabilities before adding them to our data set, if you are getting data elsewhere it likely comes from the WPScan Vulnerability Database, which is data source where the people behind it don’t seem to be concerned about the accuracy of their data (or other things that seem important for providing what they claim to provide).

If they were even a little concerned about that it seems hard to believe what has happened with the plugin WooCommerce PayPal Checkout Payment Gateway would have occurred. They are currently claiming that plugin, which has 800,000+ installs according to wordpress.org, contains an unfixed vulnerability: [Read more]

19 Jul 2019

Not Really a WordPress Plugin Vulnerability, Week of July 19

In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release 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. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Persistent Cross-Site Scripting in OneSignal Push Notifications

If there had actually been a persistent cross-site scripting (XSS) vulnerability in the plugin OneSignal Push Notifications as claimed, that would be a big deal as that is the kind of vulnerability is fairly likely to be exploited and the plugin has 100,000+ installs. No explanation of the vulnerability beyond a proof of concept was provided. The first thing that we noticed that raised questions about this was the URL that the request to exploit this would be sent to: [Read more]

12 Jul 2019

Not Really a WordPress Plugin Vulnerability, Week of July 12

In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release 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. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Path Traversal in Ad Inserter

One of the changelog entries for version 2.4.20 of Ad Inserter is “Fix for path traversal vulnerability – credit to Wilfried Bécard of Synacktiv (https://synacktiv.com)”. The relevant change looks to have replacing the following lines: [Read more]

5 Jul 2019

Not Really a WordPress Plugin Vulnerability, Week of July 5

In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release 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. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Easy Forms for Mailchimp

One of the changelog entries for version 6.5.3 of Easy Forms for Mailchimp is “Fixed admin input field code injection vulnerability. Thanks to Henri Salo from Nixu Corporation for finding and reporting this to us.” The relevant change looks to involve this line: [Read more]

7 Jun 2019

WPScan Vulnerability Database Leaving Those Relying on It Unaware of “Vulnerability” in Plugin With 500,000+ Installs

When it comes to getting data on vulnerabilities in WordPress plugins what we have noticed is that many sources are not using unique data, but instead reusing data from another source, often without letting people know what the true source is and never with a disclaimer about the quality issues that are inherent in that data source. That source is the WPScan Vulnerability Database, but recently we realized that they in fact are often just copying their data from yet another source. That source being the Common Vulnerabilities and Exposures (CVE) system. As we have more closely monitored that source recently we have noticed plenty of issues with it. This week we noticed something that wasn’t as much concern, but does present a worse picture of the WPScan Vulnerability Database.

Earlier this week CVE-2019-12566 was published, which involves a claimed stored XSS vulnerability in WP Statistics, which has 500,000+ installs according to wordpress.org. The summary for that is: [Read more]

13 May 2019

WPScan Vulnerability Database Spreads Easily Checkable False Claims of Vulnerabilities in W3 Total Cache

W3 Total Cache is one of the most popular plugins in the WordPress’ Plugin Directory, with 1+ million active installations according to wordpress.org. Last week a new version was released where one of the changelog entries is “Improved security on calls to opcache flush”. Notable it didn’t claim that any vulnerabilities were fixed in that, but if you were relying on other data sources on vulnerabilities in WordPress plugins you were told that there were two ones fixed related to that change, which clearly shows that these other data sources don’t actually confirm or validate claimed vulnerabilities before adding to their data set.

The main culprit for that situation was the WPScan Vulnerability Database which was the source others like WPCampus and ThreatPress then copied their data from. [Read more]

10 May 2019

While Others Mislabel a Possible Vulnerability, We Find a Vulnerability in Custom Field Suite

The changelog for the latest version of the WordPress plugin Ultimate FAQ is “Fixes a minor possible XSS issue”, we don’t know where the possible part comes from since that fixes a vulnerability and when we contacted the developer about that vulnerability we offered to provide them a proof of concept that confirmed that vulnerability was in fact exploitable. Vulnerabilities being inaccurately referred to as a possible or potential vulnerability isn’t an uncommon issue. By comparison the changelog for the latest version of Custom Field Suite is “Fix: prevent possible XSS for logged-in editors or admins (props reddy.io)” and what was fixed there would actually be a described as a possible vulnerability, since it involves allowing those users to do something they normally are permitted to do anyway due to them normally having the “unfiltered_html” capability.

Unfortunately, unlike us, other data sources don’t seem to care much for accuracy as that was added to the CVE’s data without that important qualifier: [Read more]

2 May 2019

Did Sucuri Lie About a Claimed SQL Injection Vulnerability or Unnecessarily Frighten People Due to Not Doing Basic Testing?

Yesterday we wrote about the web security company Sucuri overstating the impact of a SQL injection vulnerability, which they had re-discovered a year and half after we had discussed it. That was one of two claimed SQL injection vulnerabilities they disclosed recently and the post on the other, claimed to be in the plugin Advance Contact Form 7 DB, manages to be worse.

Their post starts by making a claim that doesn’t seem to make sense: [Read more]

5 Apr 2019

Not Really a WordPress Plugin Vulnerability, Week of April 5

In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release 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. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Open Redirect in Feed Statistics

A common source of claimed vulnerabilities in these posts for the past few months has been someone with the handle “KingSkrupellos” that the website Packet Storm keeps posting inaccurate reports from. We have contacted them about this and they removed the following report, but most, if not all, of the others from this person are still up. With their claim of an open redirect vulnerability in the current version, 4.1, of Feed Statistics, the proof of concept they provided doesn’t work, which you would assume someone putting out a report would check on before putting it out. If you look at the code they show, that isn’t surprising, as among a number of issues, the user input they are saying is used, isn’t used in that code. What looks to have happened here is that they copied from previous reports of the same vulnerability that look to be based on people running across websites using very out of date versions of the plugin. There actually was an open redirect vulnerability in the plugin but that was fixed in August, 2014. [Read more]