Often when we review claims about vulnerabilities in WordPress plugins, we find that the issues have only been partially addressed. That is the case with a vulnerability in the plugin POST SMTP, which has 300,000+ installs. The plugin vulnerability data provider WPScan released a rather vague report about a vulnerability in that in June. It lacks a lot of information, like what the vulnerable code is or how it was fixed. It does contain this note:

Note: The AJAX actions are also affected by SQL injections, making the issue easier to exploit by being able to choose which email to resend, for example the latest email related to a password reset

Based on that, there are a couple of things that WPScan and other providers would want to check on. First, was the SQL injection vulnerability fixed. Second, where there anymore SQL injection issues.

One method we have for testing out SQL injection vulnerabilities is in development protection for our firewall plugin against SQL injection attacks. When trying the proof of concept provided by WPScan with that running, curiously, we found that with the version that was supposed to address this; the request was still being blocked for SQL injection if we used a valid nonce.

Looking at the code, we found multiple basic security failures that still allow SQL injection to occur in the plugin.

The vulnerability involved a function named resend_email() in the file /Postman/PostmanEmailLogs.php. The code relevant to the SQL injection takes the value of the POST input “id” and passes it to another function, get_log():

656
657
658
659

$id = sanitize_text_field( $_POST['id'] );
$response = '';
$email_query_log = new PostmanEmailQueryLog();
$log = $email_query_log->get_log( $id );

While that value is sanitized, it isn’t sanitized for use in a SQL statement or properly sanitized. The value should only be an integer and yet the function for sanitizing a text field, sanitize_text_field(), is used. That shouldn’t be an issue as long as a prepared statement is used for any SQL statement that includes that input, but that isn’t the case. Instead, the value is used directly in such a statement in the function get_log():

270
271
272
273
274
275
276
277

public function get_log( $id, $columns = array() ) {
 
	$columns = empty( $columns ) ? '*' : implode( ',', $columns );
 
	return $this->db->get_row(
		"SELECT {$columns} FROM `{$this->table}` WHERE id = {$id};",
		ARRAY_A
	);

That isn’t a one-off issue. The function right above that in the same file, /Postman/Postman-Email-Log/PostmanEmailQueryLog.php, is similarly not properly secured:

249
250
251
252
253
254
255
256

public function get_all_logs( $ids = array() ) {
 
	$ids = implode( ',', $ids );
	$ids = $ids == -1 ? '' : "WHERE id IN ({$ids});";
 
	return $this->db->get_results(
		"SELECT * FROM `{$this->table}` {$ids}"
	);

Another function in the file that still isn’t properly secured against SQL injection is part of another vulnerability that WPScan had disclosed at the time.

Patchstack Vulnerability Disclosure Program (VDP)

Heading to the page for that plugin on the WordPress Plugin Directory to see about notifying the developer of the unresolved issues, we found that there is a FAQ entry on reporting security bugs, with this answer:

You can report security bugs through the Patchstack Vulnerability Disclosure Program. The Patchstack team help validate, triage and handle any security vulnerabilities. Report a security vulnerability.

What? Why would someone trying to report a security bug in this plugin to the developer instead contact a third-party vulnerability data provider? They obviously can’t address security vulnerabilities in the plugin, since they are not the developer. Clicking the link brings you to this page, which doesn’t appear to be a page for reporting a vulnerability:

Instead, it is listing of vulnerabilities in the plugin. Notably, two of those are the vulnerabilities disclosed by WPScan that haven’t been fully addressed.

Clicking around, we did find a page for Patchstack’s VDP, which says this:

This is the official vulnerability disclosure program for Post SMTP Mailer/Email Log. If you’re a security researcher and believe that you have found a security vulnerability within our software, please send us details through the “report” form on this page. Please include as detailed information as possible, so we could verify the issue and get back to you as soon as possible with either additional questions or with a potential fix. All valid security vulnerabilities will receive a CVE and may also earn you rewards from Patchstack Alliance bug bounty program.

Note the limited mention of actually fixing issues, which is what someone trying to get an issue fixed would be interested in.

The report form mentioned there similarly seems to be focused on providing them with data for them to sell, instead of being focused on actually fixing issues. Some of the information required is entirely irrelevant to fixing it.

Worse still, with the report form, that is focused on vulnerabilities, not security bugs. Not every security bug or security issue is a vulnerability. The SQL injection issue we noted above wouldn’t be a vulnerability on its own, an attacker needs to be able to access the code. But that isn’t a reason not for it to be reportable, since it is a security issue even if an exploit isn’t possible now.

Considering that the plugin still contains the SQL injection that Patchstack should know about, since they know about WPScan’s reports on the related vulnerabilities, it doesn’t appear that Patchstack is able to handle triaging things as the developer of the plugin suggested.

We notified the developer directly on Tuesday of the remaining issues. They replied yesterday that they were looking into them.

Plugin Security Scorecard Grade for Patchstack

See issues causing the plugin to get less than A+ grade

Plugin Security Scorecard Grade for WPScan

See issues causing the plugin to get less than A+ grade