In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

SQL Injection Vulnerability in Simple Events Calendar

With a claimed SQL injection vulnerability in the plugin Simple Events Calendar the claim seems shaky before even getting in to the details as it is stated that “Type user acces: administrator user.” If a vulnerability has to be exploited by an Administrator it likely isn’t a vulnerability, since those users normally have the ability to do almost anything (including editing a plugin to remove security code or adding another plugin that can take the action that could be done through the vulnerability).

Where there still could be an issue is with cross-site request forgery (CSRF), which causes a user to take an action they didn’t intend to. The plugin doesn’t include protection against CSRF before the claimed vulnerable code runs, which ends up being part of a real vulnerability we saw while reviewing this claimed vulnerability (and we will disclose that after the developer has had a chance to fix it). With the type of SQL query in claimed vulnerable code that could mean there is a vulnerability if the value of a GET input is involved (which is something we really should have put up a post on by now), but in this case the value involved is from a POST input:

312
313

$edit_event = $_POST['event_id'];
$update = $wpdb->get_results(" SELECT * FROM $table_name WHERE id = $edit_event ", "ARRAY_A");

Since an attacker can’t get back the result of the query in through CSRF in this situation, there isn’t a vulnerability there. While there isn’t a vulnerability, the code could be improved by using a prepared statement and validating the input (since it should only be an integer).

The person behind the claim stated that “Vendor no finded”. We are not sure what that means as the developer’s website is listed both on the plugin’s page on the Plugin Directory and in a couple of place in the WordPress admin area when the plugin is installed. We have notified the developer of the disclosure and the possible improvements.