Wordfence Has Also Been Falsely Claiming That WordPress Plugins Contain Vulnerabilities
Yesterday and today we have been documenting an absolute mess in the WordPress security space. The developer of the Freemius library, which is widely used in WordPress plugins, was warned by us in February of last year of a security issue (there multiple issues, some of which they resolved at the time), which they didn’t fix at the time and instead lied about us. Recently, they finally addressed it (with another security provider taking credit for discovering the issue). That was bad, but where things got a lot worse is that various security providers and their clients have been falsely claiming that WordPress plugins were still vulnerable due to this. In some cases, the plugins had already updated Freemius weeks ago to fix this and in others, the plugins didn’t even contain the library. So far, we have documented instances involving Patchstack, iThemes Security, WP Engine, WPScan, and Really Simple SSL. Considering their track record, it isn’t surprising that Wordfence was also a part of this.
Wordfence provides inaccurate plugin vulnerability data that is available to others and is also utilized by their very popular Wordfence Security Plugin.
In this situation, Wordfence managed to both to claim a plugin that had already addressed this hadn’t and claimed another plugin that didn’t even have the library was vulnerable. What looks to explain this is poorly implemented automation, without basic sanity checks.
With one of the plugins, TI WooCommerce Wishlist, Wordfence is claiming that the vulnerability isn’t fixed and listing the vulnerable versions as 1.1.12 – 1.6.2:
The current version of the plugin is 2.7.3. Version 1.6.2 hasn’t been the current version since version 1.7.0 was released in May 2018. The changelog for that version lists Freemius being removed.
We can’t think of a reasonable explanation for Wordfence claiming this hasn’t been fixed. It also still hasn’t been corrected, despite discussion of the problem showing up in something that Wordfence should be monitoring to make sure their vulnerability data is warning about serious issues.
With another plugin, things are not as bad. Here is how the listing looks now:
And here is how it looked before:
Previously, the newest vulnerable version listed was 2.4.6.230518, but the latest version at the time was 2.1.2.230718. That earlier version is the one they now list as fixing this. The explanation suggested by someone for that higher version being listed is:
The issue was caused by a tagged version with the higher version number, that probably was never really released. You might want to consider to remove that tag.
Where was the sanity check to flag if a tagged version is higher than the available version? With our own data entry system, we have checks for affected version numbers to help avoid issues similar to that. But based on our experience, relying on that sort of automated tag checking is going to produce some rather inaccurate information even, if you avoid both of those problems.
While falsely claiming that plugins are vulnerable when they are not is an issue, the larger issue is the lack of verification work being done by Wordfence. That frequently means those relying on their data are being told vulnerabilities have been fixed when they haven’t. Those unfixed vulnerabilities sometimes are widely exploited, as was the case with one earlier this year.