What to Do If Someone is Claiming There is a Vulnerability in Your WordPress Plugin
In the work we do to keep track of vulnerabilities in WordPress plugins for our customers, we see a lot going wrong with the handling of vulnerabilities in them. While a lot of that involves plugin developers, it also involves others as well, and is leading to frequent problems that could be better handled. Below we have touched on our advice on dealing with a claim that a vulnerability in your WordPress plugin based on our experience helping to address those.
If there is something more to be noted, leave a comment below.
Is There a Vulnerability?
The first thing to determine is if there really is a vulnerability or at least a security issue. It isn’t uncommon for there to be claims of vulnerabilities where there really isn’t a vulnerability. In a lot of those cases, there is less than ideal security. Even if there isn’t a vulnerability, addressing a security issue is a good idea. How can you tell if there is a vulnerability? If the attacker can do something through your plugin that they already normally can do another way, it isn’t a vulnerability. For example, someone logged in to WordPress as an Administrator can already upload arbitrary files, so it wouldn’t be a vulnerability for them to do that, as was recently claimed by a couple of security providers.
Fix the Vulnerability
Trying to explain how you can fix any type of vulnerability in a WordPress plugin is outside the scope of this post, but we would recommend carefully reviewing WordPress’ documentation related to whatever you are addressing. Even very popular security plugins are not doing that now, leading to less than ideal security. If you are not sure how to fix it, reach out to others for help.
Confirm That The Issue is Fully Addressed
Once you think you have fixed the vulnerability, confirm that the vulnerability has really been fixed. What we see over and over is developers failing to actually fix vulnerabilities. So make sure the vulnerability has been fixed. The person contacting you should be willing to review the fix. If they are willing, take advantage of it. If not, try to find someone else who will.
Something else you should check on is if there are additional instances of the vulnerability that were not reported to you. It is very common for us to find that is still the case after plugin updates that were supposed to have fixed vulnerabilities.
You should also use this as an impetus to check for other security issues in the plugin. The best option would be to have a third party do a security review of the plugin for you.
Forced Update?
WordPress has the ability to force out updates to WordPress plugins. The criteria and process for that are not well explained, and it doesn’t seem like what they are saying about that matches up with what has actually happened. But if there is a serious vulnerability being fixed in the plugin, it would be a good idea to see if the team will utilize that with your update.
While that could be useful after an update has been released, in the past it has been claimed that it can only be used if the update hasn’t already been released. So take it up with the team first. We should provide the warning that dealing with the team can go poorly, because of problems with the team members’ ability to work with others. So you may want to avoid complications by avoiding trying to interact with them.
What to Say in the Changelog
What you should say in the changelog about this doesn’t have an easy answer. Recently, it was claimed by some WordPress security providers that there had been a reflected cross-site (XSS) vulnerability in WooCommerce that there hadn’t been, after there was a changelog entry saying that the “potential for a Reflected XSS” was addressed. So trying to be more forthcoming can lead to others causing problems.
Right now developers are all over the map in what they say. Some don’t mention security fixes at all, while others provide quite a bit of detail. We would say providing more information is better, but it can have downsides, as the example with WooCommerce shows.
While it is considered good form to credit discovers, that isn’t required. If you are going to do that, make sure it is the actual discoverer. Some security providers, including Patchstack, Wordfence, and WPScan, are directing vulnerability reports away from developers to themselves. Don’t reward that by crediting them instead of the actual discoverer.
Make Sure the Version Number Has Been Changed
A problem we have seen for many years that still happens is that developers sometimes forget to increase the plugins version number when fixing a vulnerability. That’s a big problem if there is a serious vulnerability, as no one already using the plugin will get an update. Less common is for there to be some other mistakes being made, leading to users not getting the new version. So double check that the WordPress Plugin Directory is listing a new version number for the plugin after you release the update.