To provide our customers the best data on vulnerabilities in WordPress plugins they are using or thinking of using, we spend a lot of time looking in to things that turn out not to be vulnerabilities. One of the things that leads to that is our monitoring of the WordPress Support Forum for topics that may be bringing those up. Recently that brought us across a topic with claims of a vulnerability or intentionally malicious code in a plugin. The topic started a couple of weeks ago with this claim:

Activating this plugin redirects visitors to vpn and spam links.

The developer responded that “no official version which includes any spam links or redirects in any way in this plugin”.

Several days ago there was a follow up from someone else, stating this:

Guess what, I have the exact same problem. And I got the plugin from WP Repository only.

The developer responded asking for more information.

That was at the point we ran across this. Looking at this there was previously a vulnerability in the plugin due to third-party library and hackers have been widely attempting to exploit that in general recently, so it is was possible that was the source of issue, though what that hack allows wouldn’t necessarily be used to cause what was claimed to be happening. It also wouldn’t explain what could have caused the first person’s claim that the issue occurred when activating it. We then checked over the plugin to see if there might be another vulnerability still in the plugin that matched what was described, but we didn’t find anything.

We then were watching to see what follow up the second person claiming there was issue might say and the response told an all too common story:

Alright, so that was a false positive, I had reviewed the full website of the client and found another plugin to have this serious vulnerability issues.

Since Age Gate pops up first and site immediately redirects to spam link, your plugin became the soft target. Apologies.

Over the years we have seen plugins repeatedly blamed for all sorts of issues they had nothing to do with.

In this situation what seems worth noting is that it would be a perfect situation for using our service, since right at the beginning this person could have seen what vulnerabilities any plugins in use on the website have had and if they were in the versions currently being used (that is something we uniquely actually provide as far as we are aware). If they then had any questions about those vulnerabilities, say if the vulnerability matches what is occurring on the website, someone on our end familiar with the particular vulnerability could have responded. If the service was being used before the website had been hacked we likely would have warned them about the vulnerability before it was exploited or at least before they noticed it had been exploited.