Nearly two years ago we looked over the vulnerabilities that were in our data set at the time to get a better understanding of how often security fixes are left out of the changelog entries for the version of the WordPress plugin that fixed it. We found that nearly 20 percent of the time no mention was made of a vulnerability being fixed (that included one instance were the vulnerability was being exploited before it was fixed). That is a good reminder that you really need to be keeping your plugin update at all times since there is good chance you won’t know that an update includes a security fix.

Vulnerabilities fixes being left out of the changelogs is not the only issue with getting accurate information from the changelogs. We also find that sometimes vulnerabilities are incorrectly describe as possible or potential vulnerabilities. In the previously mentioned analysis we also found that  15 percent of the vulnerabilities were inaccurately labeled as either being a possible or potential vulnerability. A possible or potential vulnerability would accurarelty refer to a situation where there is code that isn’t properly secured but there isn’t a known way to exploit that code. For example, a plugin might have a database query that isn’t properly secured against SQL injection but no one who looked at the issue figured out how to get malicious code passed to the query. That obviously isn’t as much concern as a vulnerability that is known to be exploitable and depending on security requirement in an organization that may alter the amount of post disclosure checking that needs to be done.

Since the average plugin developer isn’t likely to be too familiar with security that mislabeling is somewhat understandable, but when it comes from a security plugin it is harder to understand how that could happen. While reviewing a vulnerability disclosed in the plugin All In One WP Security & Firewall yesterday we found that in the changelog for the version with the fix, 4.2.0, it states that

Fixed a few potential XSS vulnerabilities.

The vulnerability is common type, a reflected cross-site scripting (XSS), and is easily exploited as can be seen with the proof of concept included with the report, so we can’t understand how it could have been mislabeled (six additional changelog entries for other versions refer to potential vulnerabilities as well).

This is the same plugin that we discussed earlier this week due to one of its developer’s belief that it is normal for security plugin’s to contain security vulnerabilities, so concern for security doesn’t seem to be all that important among its developers.