We often see confusion over the potential impact of one type of vulnerability, SQL injection, that can exist in WordPress plugins. The confusion seems to stem in part from the name of the vulnerability, though that doesn’t explain it entirely. The SQL part refers to a SQL statement, a query being made of a database, but it is easy enough to think that refers to the database itself. With the misinterpretation, then this would refer to database injection, or injecting something into the database. Confusion over this was recently spread by a journalist not really doing journalism.

A recent Bleeping Computer story by Bill Toulas involved SQL injection vulnerabilities in three WordPress plugins. He accurately described what SQL injection is:

SQL injection is a website security flaw that allows attackers to input data into form fields or via URLs that modify legitimate database queries to return different data or modify a database.

SQL injection is a website security flaw that allows attackers to input data into form fields or via URLs that modify legitimate database queries to return different data or modify a database.

Here is how he then described the potential impact of this type of vulnerability:

Depending on the website code being vulnerable to a SQL injection flaw, an attacker could modify or delete data to a site, inject malicious scripts, or gain full access to the website.

At the end of the story, he wrote this:

While all of these plugins were vulnerable to SQL injection, and proof of concept exploits were released, Tenable did not share what impact they could lead if exploited in attacks.

So he ran with a potential impact and only at the end noted he didn’t know what the impact was. More problematic, he didn’t reach out to an additional source who could have told him the impact of these vulnerabilities isn’t directly any of those things. Having a second source would be journalism.

To get a better idea of what actually is possible with this type of issue, let’s take a look at the code causing one of the vulnerabilities mentioned. The following line of code takes user input that has already been passed to the variable $code into a SQL statement:

936

$id = $wpdb->get_var("SELECT id FROM $wpdb->pmpro_membership_orders WHERE code = '" . $code . "' LIMIT 1");

That’s SQL injection.

The first word in the SQL statement there is SELECT. That is “used to retrieve rows selected from one or more tables, and can include UNION operations and subqueries”. There are quite a few other types of statements. That type of statement doesn’t allow doing things that Bill Toulas mentioned. If you want to modify or delete data, the UPDATE and DELETE statements would be required. So that SQL injection vulnerability would only allow actions that involved reading data. That is also the case with the other two vulnerabilities mentioned.

That all three vulnerabilities only allowed reading data isn’t surprising, as it is highly uncommon for an SQL injection vulnerability being found in a WordPress plugin to involve something other than a SELECT statement. That limits the potential damage of these vulnerabilities, since many WordPress websites don’t contain any sensitive information in the database that would be easily useful to a hacker.