Among the many areas where there seems to be confusion over security when it comes to WordPress websites, and websites more broadly, is a type of vulnerability known as SQL injection. SQL is short for Structured Query Language, a language used for communicating with some databases. SQL injection involves injecting malicious code into SQL statements, causing code specified by the attacker to run against the database. What can be done through that depends on the specifics of the vulnerability, but in most instances with WordPress plugins all that can be done with that is to slowly read out the contents of the database. What often gets referred to as SQL injection, involves any changes being made to the database, which in recent history with WordPress plugins being exploited, almost never involves SQL injection.

One of the ways we keep up with vulnerabilities in WordPress plugins, so that we can warn customers of our service about any of them that impact them is by monitoring topics on the WordPress Support Forum related to them. These days though what we are usually finding though is that vulnerabilities we already warned our customers about are now being exploited. That was the case with an arbitrary file viewing vulnerability in the plugin Advanced Access Manager that we warned our customers about on the 5th when it was fixed. We rated the vulnerability as having a high likelihood of exploitation. Early on the 7th a topic was started on the forum that appears to be due to that vulnerability being exploited.

There are multiple instances in the topic incorrectly referencing the exploitation involving SQL injection:

Yes exactly, it came back after one day of removing… i think it is an sql injection

I made a file change scan and I think NO file was changed. I am pretty sure that this is a sql injection.

I checked the logs. There was a SQL insertation on my websites at:

The confusion is important for a number of reason.

One of them being that properly resolving the exploitation of this is different than if it was actually SQL injection. What would have in all likelihood happened here is that the vulnerability was used to view the contents of the WordPress configuration file, which contains the database credentials. While this type of vulnerability is highly likely to be exploited, in most cases it doesn’t lead to any further damage since the hacker would still need to be able to connect to the database somehow to use the credentials. One way that can happen is if the database had remote access enabled, which usually isn’t the case, then the hacker could connect directly to it. If the hacker has a means to access the database, changing the database password is critical, since even if the vulnerability is fixed the hacker would still be able connect to the database, which isn’t true with a SQL injection vulnerability (though a hacker could use additional access they gained through SQL injection to take further action).

Another reason this is important is people often are looking for security products or services that protect against SQL injection and if that is based on confusion over what hackers are actually exploiting, then they are looking for something that won’t actually matter.

WordPress’ Lack of Interest in Reducing Hacked Websites

That topic is now closed and the last message seems telling as to the continued lack of interest by the people who are in charge of WordPress plugins in doing anything about avoidable exploitation, as was the case here. The message was written by the person in charge of the team running the Plugin Directory:

This post has gotten a bit out of hand so I’m closing this. It’s impossible to help people anymore.

AAM has been patched. If you’re using that, upgrade.

We recommend people make their OWN support posts to get help, as most issues are not the same between users.

Beyond the fact that upgrading doesn’t undo already being hacked, it seems reasonable to assume that a lot of the websites that were hacked had been hacked after this had been fixed. There are a number of options that could be considered to make sure that more people are getting fixed versions of plugins before that happens with a vulnerability likely to be exploited, but the team in charge of the Plugin Directory doesn’t seem interested in having a conversation about that, much less, taking action.