On April 5 due to our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities we disclosed an arbitrary file upload vulnerability we spotted in the plugin SupportCandy. A week after our disclosure Christian Angel independently found the vulnerability. The vulnerability was fixed on April 17.

In looking over the logs of a hacked website we were dealing with over at our main business we found that attempts to exploit this vulnerability have been occurring since at least April 20, though in a way that can fail even if a website is using a vulnerable version of the plugin. The exploit attempts involve sending a POST request to:

//wp-admin/admin-ajax.php?action=wpsc_tickets&setting_action=rb_upload_file

Someone looking at the proof of concept included in our report shouldn’t have done it that way since that won’t work by default. The reason for that is that if you try to exploit it by sending that request by itself, it won’t work unless a directory has already been created by the plugin (due to a limitation of the function move_uploaded_file()). In our report we mentioned that limitation and that other code allowed dealing with it, and our proof of concept dealt with that by showing that you would send another request first. But in the other report on that vulnerability it isn’t mentioned. It appears that person writing that didn’t fully understand and or test things out as they even provide Python code to exploit this (“exploitation” is the term they used for that), which doesn’t address that:

1
2
3
4
5
6
7

import requests
 
url = 'https://localhost/wp-admin/admin-ajax.php?action=wpsc_tickets&setting_action=rb_upload_file'
files = {'file': open('shell.php', 'rb')}
 
r = requests.post(url, files=files)
print r.text

If the directory was already created through other usage of the plugin then the exploitation attempts could still work.

No Warning

You would assume that other data sources on vulnerabilities in WordPress plugins would have this vulnerability in their data sets considering the severity of the vulnerability, the public disclosure by two different entities, it having a CVE number (which others treat as a big deal), and that it is now receiving exploit attempts, but to use as an example the WPScan Vulnerability Database, others still missing it from their data sets: