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.

One reason this is the case is that many hackers don’t have much clue what they are doing, as an example when just ran across shows.

One of the ways we keep on top of vulnerabilities in plugins, so that we can make sure your website remains protected against them, is to monitor attempts to hack our websites. Yesterday one of the attempts on this website involved sending a POST request to the file /wp-content/plugins/robo-gallery/includes/rbs_gallery_ajax.php. This was attempt to exploit a claimed vulnerability in the plugin Robo Gallery. We don’t have that plugin installed so there is no chance it could have been exploited.

But even if we did have the plugin installed, it would not have had any chance of being successful since, as we discussed last week, the claimed vulnerability doesn’t actually exist. As we noted then one of the problems with this being a real vulnerability is that you can’t access the supposedly vulnerable file, /includes/rbs_gallery_ajax.php, directly due to the second line of code in the file:

if ( ! defined( 'WPINC' ) )  die;

That code checks WPINC is defined, which it won’t be if you access the file directly, and if isn’t the rest of the file doesn’t get executed. If the file is loaded by WordPress, WPINC will be defined, since it gets defined in the /wp-settings.php, which is loaded at the end of the file /wp-config.php.

What is somewhat interesting about this is the hacker didn’t just follow the proof of concept provided with the advisory, since they would have done a GET request instead of a POST request if that were the case. The correct request type would be a POST, so clearly the understood part of the advisory was wrong, but they missed the larger problem with it, that you can’t get to the part of the file where that matters due to the previous issue.