With our service we warn our customers if WordPress plugins they use contain publicly known vulnerabilities (many of which we have also discovered). When we are warning them we have already confirmed that there is an issue and we are available if they have any questions about the dealing with the issue (say if the plugin has been closed on the Plugin Directory, so they can’t update to a fixed version easily). With a competing data source, the WPScan Vulnerability Database, those things don’t happen and instead all sorts of unnecessary headaches are caused. We saw one such example yesterday.
In an email alert for the WordPress Support Forum we have set up to let us know discussions possibly related to vulnerabilities in plugins we got alerted to this message:
@dlynch027 I’ve removed your post “1.17.6 Still Vulnerable to Stored XSS Attack” for the OneSignal – Web Push Notifications plugin.
If you are aware of a vulnerability for this plugin, please send the details to email@example.com instead of here.
That was from the frequently problematic moderator Jan Dembowski. While we didn’t see original message they were replying to, the author of it later wrote this:
Stop deleting threads without answering the incredibly critical question.
Do I need to delete the plugin for my websites to stay secure or is just deactivating them (until a new update is available) good enough?
There are multiple problems with all of that.
One of them being that this refers to a report of a vulnerability publicly disclosed a week ago. It doesn’t make sense that a moderator is deleting someone asking a question about that, seeing as the bad guys would already know about it. If there was proper governance of the WordPress the team running the Plugin Directory should already know about it as well and taken appropriate action (there isn’t proper governance).
The second problem with this is that the claimed vulnerability doesn’t exist, as we explained in a blog post last Friday:
After seeing that we did a search of the plugin’ code to see if valid value for that is checked for. When we did that we found that to be able to change the settings that the proof of concept causes to be changed, someone needs to be logged in as Administrator and have a valid nonce, so there really isn’t a vulnerability here.
That information was already provided to our customers if they are using that plugin. That is something someone could have explained to the person concerned about this in the original topic, but they can’t do that when a moderator has deleted the topic. With their additional topic the developer was able to explain that in more detail.
The original report about the claimed vulnerability this doesn’t refer to a “stored XSS”, instead referring to”persistent cross-site scripting”, what does and matches up time wise with the topics about this, is with the WPScan Vulnerability Database’s entry claiming there is a vulnerability:
The description there indicates that whoever was behind that entry doesn’t understand what they are talking about:
The issue required a valid nonce, is still present in the latest version (1.17.6) of the plugin and has been reported to WP Plugins Team
As we already mentioned last Friday, you don’t just need a valid nonce, you need to be logged in as an Administrator, who already have the capability to do the equivalent of what the vulnerability is supposed to be here.
In the past when WPScan’s data was getting stuff wrong like this they didn’t claim the vulnerability was verified, but as part of the quality of their work getting worse, they did here.
What all of this seem more ridiculous, while the moderators delete people trying to discuss claims of vulnerabilities, the WPScan organization is allowed to have a plugin in the WordPress Plugin Directory that propagates false claims like this. So false information is okay with WordPress trying, to clear it up isn’t. With that plugin they are even now trying to get people to pay them for access to their data, despite it being of such low quality and there already being a better service, namely ours, avaialble.