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.
Today we have had a lot of traffic coming to our website to our posts about the vulnerabilities fixed and unfixed in the plugin Easy WP SMTP. The likely explanation is what else we have been seeing today, as in terms of dealing with the cleanup of hacked WordPress websites over at our main business and other mentions of hacked websites, we are seeing indications that the option update vulnerability that was fixed with that and possibly the other recently fixed option update vulnerability impacting many plugins are being exploited widely to change the WordPress option “siteurl” on websites to cause requests to be made to “getmyfreetraffic.com” (based on past experience with this type of vulnerability that likely isn’t the only thing the hackers are doing with the vulnerabilities on those websites).
If you want the best information and therefore best protection against vulnerabilities in WordPress plugins we provide you that through our service. Here is what we did to keep those are already using our service secure from WordPress plugin vulnerabilities during November (and what you have been missing out on if you haven’t signed up yet).
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:
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 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.
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.
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).
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.