In our dealing with hacked websites we have recently been working with quite a few people that have come to us after trying to do some work to figure out the source of the hack themselves. They will bring up that they have found reporting that software on the website has had vulnerabilities and those might have been the cause. In reality most of those vulnerabilities have very little chance of being the cause of a website being hacked in general and in some cases they have no chance since the vulnerability didn’t actual exist.

Narrowing down what vulnerabilities could be a possible cause of a website being hacked is good use of our service (and then going forward, getting ahead of vulnerabilities in your website’s plugins by having them reviewed for security issues by us and getting notified of if vulnerabilities are discovered in the version of them you are using).

One of the pieces of data that is uniquely included in our data is an estimation of how likely a vulnerability is to be exploited, which is largely based on our years of experience dealing with hacked websites.

Another couple of important aspect of what we uniquely do when it comes to WordPress plugin vulnerability data is weeding out false reports of vulnerabilities, so you only have to look through real vulnerabilities, and letting you know which versions are impacted (as vulnerabilities can impact as little as one version of a plugin, so outdated version in use on a website might not be vulnerable).

We just ran across a good example of false report of a vulnerability, which involves the plugin Spider Event Calendar (Calendar by WD). A report was released claiming that plugin contained a blind SQL injection vulnerability that could cause:

Public defacement, confidential data leakage, and database server
compromise can result from these attacks. Client systems can also be
targeted, and complete compromise of these client systems is also possible.

While that sounds scary and likely to lead to a website being hacked, the reality is that this type of vulnerability would usually only allow slowly reading out the data from a website’s database and we don’t see that being used by hackers on a wide scale at this time. It could be used in a targeted attack and would be of great concern if sensitive data was stored in the database in that situation.

What makes this false has to do with how the issue could be accessed. The report states that:

To exploit the vulnerability only is needed use the version 1.0 of the HTTP
protocol to interact with the application.

In reality the page where the report states the request would be sent to is only accessible to those who are logged in as Administrators (technically those with the manage_options capability, but usually only Administrators have that capability). Administrators normally have the ability to edit plugins, so they could remove any protection against this issue, and the ability to add plugins, so they could add a plugin that allows them to more easily access the data in the database than this issue would permit. While it would be accurate to call this issue a bug, calling it a vulnerability doesn’t seem accurate. If someone has access to an Administrator account then the website likely has much bigger issues than this as well.

It doesn’t look like the omission that accessing this issue requires being an Administrator was unintentional, as we previously interacted with person behind this report to point out that another claimed vulnerability not only required being an Administrator, but involved taking an action they would normally be specifically permitted to do. They stated they were aware that it was only accessible to Administrators, but apparently didn’t feel the need to note that. When they later released a report on the claimed vulnerability they left out any mention that it required being logged in as an Administrator as well.