_{As part of our cataloging the vulnerabilities in WordPress plugins for our service we come across false reports of vulnerabilities from time to time. So that others don’t spend their time looking over these as well we post our findings on them.}

Last week a reflected cross-site scripting (XSS) vulnerability was claimed to be in the eShop plugin. In a sign that the claimed vulnerability was not properly reviewed before the report was published, the Exploit Code section of the reporty simply contains a vulnerability identifier instead of actual exploit code. If the discoverer had tried to create exploit code for the vulnerability they thought existed they would have seen that it didn’t actually exist.

The report claims that “The following code snippets do not sanitize user input before passing back to the browser via $_GET request.”, specifically page & action variables. Both variables are in fact sanitary when used, for different reasons.

The file in question, /eshop-orders.php, is loaded when the page variable is set to “eshop-orders.php”, so if you were to set the page variable to something malicious instead the code would not be loaded and therefore there isn’t an issue there.

For the action variable, the reporter missed lines 18-23 of the file which in fact sanitize the variable:

$eshopactionarray=array('Completed','Pending','Failed','Waiting','Sent','Deleted');

if (isset($_GET['action']) && in_array($_GET['action'],$eshopactionarray) )
	$action_status = esc_attr($_GET['action']);
else
	$_GET['action']=$action_status = 'Pending';

That code checks if the value of the variable is set to ‘Completed’, ‘Pending’, ‘Failed’, ‘Waiting’, ‘Sent’, or ‘Deleted’. If it isn’t set to any of those it is changed to ‘Pending’, so if the variable was set to malicious it would be replaced with that.