You Need to Make Sure Proof of Concepts for Vulnerabilities in WordPress Plugins You Use Have Been Tested
Are you relying on a security provider to warn about vulnerabilities in WordPress plugins you use? Are you not testing out the proof of concepts for those vulnerabilities because the security provider claims they are verifying things for you or because you don’t have the capability to do that? If you answered yes to both of those, we have bad news for you, as many of those providers are not doing that testing either, leaving websites vulnerable running still vulnerable plugins and hackers with a info on how to exploit them. A recent example of that involves a plugin with 20,000+ installs where most data providers recently claimed that there was a known vulnerability in the plugin that had been fixed, despite the proof of concept contradicting that.
Here was the original source of the claim, Automattic’s WPScan, making it (and claiming they had verified their information):
Here’s was Wordfence making it as well:
And here was Patchstack, which claims their data is “[h]and curated, verified and enriched vulnerability information by Patchstack security experts”:
The proof of concept WPScan provided is easy to test out, as all you have to do is to add a shortcode to a post and confirm that the malicious code in it runs. What happens if you tested that out?
When we tested this, we confirmed that the vulnerability worked as of the version before it was supposed to be fixed. Upgrading to the next version of the plugin should have neutralized the malicious code, but it didn’t. The same was true with the only subsequent version that had been released.
When we add vulnerabilities to our data set, we do that type of testing, which other providers must not have done there, but we also review the underlying code to make sure that the issue has been properly addressed. For plugins, being used by our customers, we go further and check to make sure there are not similar issues elsewhere in the code that haven’t been addressed.
If you were to look at the changes made in the version that was supposed to address it, what you find is that the developer tried to address it, but they added security in the wrong place. Instead of adding sanitization for user input coming from shortcode attributes, they added it to default values if the shortcode attributes don’t exist, which has no impact.
After we reviewed things, we contacted the developer about the problem and offered to help them get this fixed. They responded yesterday that they are working on a fix.
Protecting Yourself
In this situation, the threat posed is limited since an attacker would have more access than normally would have, but in another recent instance, a hacker widely exploited a vulnerability that those security providers had falsely claimed had been fixed. So either you need to do your own testing or you need to make sure your provider does that testing. Unfortunately, based on what we have seen when checking to see if other data sources have caught mistakes like this, we appear to be the only provider of this data that is actually verifying things.
Plugin Security Scorecard Grade for Patchstack
Checked on March 5, 2025See issues causing the plugin to get less than A+ grade