Last month there was report of a remote code execution vulnerability in the plugin Robo Gallery, as we discussed at the time the vulnerability didn’t actual exist (though another vulnerability did exist in the relevant code). Despite the fact that it didn’t exist and couldn’t possibly have been exploited as shown in the included proof of concept, that hasn’t stopped people from trying to exploit. We had one attempt on our website the week after the report and a recent thread on wordpress.org indicates that attempts are continuing to happen. Based on what request were sent in those two situations, those were done by different people, with the second one being from someone who was less aware of the problems with the advisory, considering they sent a GET request when that couldn’t possibly work.
When it comes to threat of websites being hacked, it is a real threat, but is also worth noting that it easy to overstate the threat. The reality is that vast majority of hacking attempts on websites have zero chance of being of successful. For less scrupulous security companies that fact can be used to do things like making it seem like their product is protecting a website from many threats that were in fact not actually any threat to the website.
While reviewing a false report of a vulnerability in the Robo Gallery plugin today we noticed the plugin actually had a privilege escalation vulnerability in the code mentioned in that other report. In version 2.0.15, and some prior versions, the function rbs_gallery_ajax_callback in the file /includes/rbs_gallery_ajax.php allows anyone logged in to WordPress to access the functions in the file /includes/extensions/rbs_create_post_ajax.php, which not all levels of users should have access to.
Today a report claiming that there was remote code execution vulnerability in version 2.0.14 of the Robo Gallery plugin was released. With such a serious vulnerability and one that was claimed to be in the most recent version of the plugin, we quickly started checking on the report to include the vulnerability in our service’s data. What we quickly noticed was the claimed vulnerability didn’t actually exist, but that that a less serious vulnerability in code mentioned in the false report does exist in the plugin. We have notified the developer that there apparent attempt to fix that vulnerability in the subsequently released version 2.0.15 was not successful. All of this highlights the importance the kind of the testing we do before adding vulnerabilities to our service’s data (and highlights the limited value of other services that don’t do that testing).