Wordfence Intelligence (and Possibly WordPress) Mishandled Unfixed Vulnerabilities in WordPress Plugin
Earlier today, we warned our customers about unfixed vulnerabilities in a WordPress plugin named Posts Like Dislike. We ran across those vulnerabilities as at least one of our customers was using the plugin and the changelog for the latest version of the plugin stated that a security issue had been fixed. Following that, we checked to see if competing data providers had also spotted that. What we found was a mess involving at least Wordfence Intelligence and possibly WordPress as well.
The latest version of Post Like Dislike added a nonce check, which prevents cross-site request forgery (CSRF), to code for resetting the plugin’s settings. The WordPress documentation for nonces is clear that is not to be used for access control:
Nonces should never be relied on for authentication, authorization, or access control.
One of our competitors providing WordPress plugin vulnerability data claims that their “database is actively maintained by some of the top WordPress vulnerability researchers in the industry”. That competitor is Wordfence Intelligence. Once again, they don’t seem to have the team they claim to have or are not utilizing them, as they are claiming that the change made to that plugin address an access control issue:
Worse still, in this case, access to the nonce isn’t limited to users who are intended to have access, so the vulnerability they are describing still exists. As we warned our customers, the issue is even broader than what Wordfence is incorrectly mentioning as being fixed, resetting the plugin’s settings.
Also, as we warned our customers, the issues also impact the plugin Comments Like Dislike from the same developer. Again, Wordfence is claiming that a vulnerability has been fixed when it hasn’t. With that, Automattic’s WPScan got in to the mix as well. Here is their inaccurate claim that it has been fixed:
In that situation, Wordfence is claiming they were able to get someone to report the vulnerability to them instead of directly to the developer of the plugin or WordPress. That isn’t what should be happening. They make a troubling claim about WordPress’ response when they reported the issue to them, after “reporting this to the WordPress plugin’s team 30 days ago we are disclosing this issue as it still is not updated.”
They made that claim five days ago. As of writing this, the plugin is still in the WordPress Plugin Directory and vulnerable. We can’t confirm if Wordfence’s claim is true, but the issue has been public for six days, so WordPress had a chance to do something by now even if they were not alerted before. (We have mentioned that to team reps for the plugin directory on Twitter.)
Leaving plugins that are known to be vulnerable in the Plugin Directory is not what should be happening. Considering the security reviewer for the team hasn’t been making sure his company’s own plugins remain free of known vulnerabilities the lack of cation is not all that surprising.
WordPress Could Help With Inaccurate Data
As this situation highlights, there is a wide gulf between what security providers are claiming to do and what they actually do. Providing inaccurate information that unfixed vulnerabilities have been fixed is a frequent problem with data on WordPress plugin vulnerabilities. In the worst-case scenario earlier this year, that led to providers falsely claiming that a vulnerability had been fixed months before it was widely exploited.
WordPress could help with this issue by warning the public about providers like Wordfence Intelligence and WPScan who are cutting corners with their data generation. The chances of that seem slim considering that WPScan is owned by the company from the head of WordPress (who also has directly employed a significant portion the plugin team in the past).