Last week we wrote a post about the fact that fairly often the changelogs of plugins don’t mention that a version includes a security fix. For that reason it is important to keep your plugins up to date all the time (our Automatic Plugin Updates plugin can handle that for you). Even when the changelog mentions that a security vulnerability has been fixed it isn’t always clear what exactly was fixed. In terms of alerting people that they need to update the plugin that doesn’t make a difference, but it does if you are dealing with a hacked website with outdated plugins or you are in an environment where you need to review the possibility the website might have been impacted by the vulnerability before it was patched.

To give you an example of this, let’s take a look at the case of  a vulnerability in two plugins that we found and has just been fixed today. In the changelog for both impacted plugins, Social Media and Share Icons (Ultimate Social Media) and Social Media, the  change is listed as:

Corner case vulnerability fixed

If you haven’t heard of a “corner case vulnerability” you are not alone, as we hadn’t heard of anything referenced as that and a Google search of the phrase in quotes pulled up a total of 33 results. We also are not sure how that would description matches the issue. In the Wikipedia a corner case is described as:

In engineering, a corner case (or pathological case) involves a problem or situation that occurs only outside of normal operating parameters—specifically one that manifests itself when multiple environmental variables or conditions are simultaneously at extreme levels, even though each parameter is within the specified range for that parameter.

The vulnerability, which is described in more detail here, allowed anyone logged in to WordPress to delete any WordPress option through an AJAX accessible function in the plugins due to a lack of two security checks as to whether the requester should be able to access the function and failure to limit what options could be deleted. We can vaguely see where the description of as a corner case vulnerability could come from that, but we think our description as an authenticated option deletion vulnerability is much clearer. With our service you would not only get that clear that clearer descriptor when looking at what vulnerabilities have existed in the plugins on a website, but you also provided with a link to the details of the vulnerability as well as the range  of plugin versions that are vulnerable (something that similar services don’t provide).

The problemswith accurate descriptions of vulnerability don’t stop with changelogs. We recently added an older vulnerability in the Tera Charts to our data, in the report of the vulnerability it is listed as a local file inclusion vulnerability, which is a vulnerability that causes a file to be included. That is, the code in the included file is run. In reality the vulnerability was an arbitrary file viewing vulnerability, which allows you to view the contents of a file. Those two types of vulnerabilities are superficially similar looking when exploited, but they are very different in their impact. With our service instead of having to dig around for the details of plugin vulnerabilities to determine if the type of vulnerability listed in the report is accurate, we have already done that for you, so you can focus on the rest of what you need to do. You also don’t need to worry about our data including false reports of vulnerabilities, since we test out each vulnerability before adding it.