When it comes to getting information on the security issues in WordPress plugins, developers of plugins are not always the best source. That is the case with a persistent cross-site scripting (XSS) vulnerability discovered by Federico Scalco that was in the plugin Caldera Forms. While that was claimed by the discoverer of the vulnerability, the developer of the plugin, and all of the other data sources of vulnerabilities in WordPress plugins we are aware of, to have been fixed in version 1.6.0 of the plugin, it actually wasn’t, as testing out the claimed vulnerability would have show any of them (the ease of testing that would will be something we will go into in another post). If you were using our service you would have been correctly notified that it hadn’t been fixed.
That has now been fixed in version 22.214.171.124. Here what the developer wrote about that:
Caldera Forms 126.96.36.199 adds the same protection in one more location and prevents the behaviour that was shown to me today.
While we are not mentioned in that, they did link to one of the data sources, the WPScan Vulnerability Database, that falsely claimed that the vulnerability had been fixed before. That isn’t the only time that the developer of that plugin has recently promoted that data source, despite the developer now knowing that they provide inaccurate data.
The other example we ran across popped up in our monitoring of the wordpress.org Support Forum to keep track of vulnerabilities in WordPress plugins. In response to someone asking about a message from the WPScan Vulnerability Database about the vulnerability the developer wrote this:
Yes, there are security fixes in 1.6.0. I worked with the developer who found and responsibilities disclosed the issues. A part of that process is registering it with the database. That documents the issue.
More importantly, it triggers alerts that plugins need to be updated on good hosts. I got a notice from WPEngine about my own site. That’s the best system available to us for getting the word out about vuldrabilites that are not severe.
We don’t think a good web host would be spreading WPScan’s inaccurate data without at least having a disclaimer that the data has serious quality issues, which might have been a reminder to the developer that they shouldn’t be promoting it. By promoting data sources that are not responsible with their data, developers are actually hurting users of their plugins, since if we didn’t exist then the vulnerability likely would have remained in the plugin for the foreseeable future. If more people knew the truth about what different data sources provided it would likely mean more customers for our service, which would mean we could be doing even more to improve the security of WordPress plugins (and therefore WordPress in general), which is already probably more than every other security company out there.
Something else we noticed that seems worth noting it terms of improving the security of plugins was something mentioned in the post announcing the release of version 1.6.0 of the plugin:
In order to ensure that this fix does prevent these potential XSS vulnerabilities, and also that we do not re-introduce the vulnerability, we have created new automated tests. These tests, which are in a private git repository, will be run on future releases and we will add additional security checks in the future.
Clearly those automated tests didn’t actually accomplish that. Just in general, our experience is that automated testing is useful as additional tool for knowledgeable professionals when checking over the security of a WordPress plugin or other software, but they have some serious limitations and their abilities are often overstated.