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 1.6.1.1. Here what the developer wrote about that:

This release is an additional fix for CVE-2018-7747 . I was alerted earlier today that there was one remaining problem that did not get fixed. The security issue that we disclosed two weeks ago is called a stored XSS vulnerability. In simpler terms that means that there was a way to use Caldera Forms to store some JavaScript that could be triggered to run later.

In Caldera Forms 1.6.0 I used a function that removes all JavaScript on the output that was previously exploitable. That prevented the stored JavaScript from running. Since exploiting a stored XSS vulnerabilities is a two step processes — store and then retrieve later — this update prevents the issue from being exploited in the future.

Caldera Forms 1.6.1.1 adds the same protection in one more location and prevents the behaviour that was shown to me today.

While we are not mentioned there for some reason, we were the ones that notified the developer of it not being fixed. The reality of the situation is that 1.6.0 had not removed “all JavaScript on the output that was previously exploitable” and the location which was claimed to be shown to them was part of the original advisory on the issue.

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.