When it comes to the chances of vulnerabilities being exploited the reality is that many types of vulnerabilities are highly unlikely to have anyone even try to exploit them. Unfortunately far too often we see security companies and the press making a big deal of vulnerabilities that are are of little to no threat, while ignoring vulnerabilities and broader security issues that are leading to websites being hacked (that lead us to providing information on likelihood that a vulnerability is to be exploited to the data for our service). When it comes to types that are likely to be exploited, the arbitrary file upload vulnerability, which allows a hacker to upload files of any kind to a website, is probably the one with the most exploit attempts and also then ends up leading to the most websites being hacked. So if a WordPress security plugin is going to protect against any type of vulnerability this seems like this is the one you would most want it to be able protect against.
At the end of last month we wrote a post about our finding that despite Wordfence’s unqualified claim that their plugin’s firewall protects against stored XSS (or what we refer to as persistent cross-site scripting (XSS)) that it did not protect against a real world vulnerability. After we posted that we though that maybe the vulnerability we used for the test wasn’t totally fair, since it required the exploiter to be logged in (or authenticated) to WordPress. Wordfence doesn’t seem to think that matters much, seeing as how the have frequently left out the detail that a vulnerability is only exploitable when logged in when disclosing them. But seeing as it severely limits the amount of website that are impacted (since many don’t allow people that are not trusted to have account), we wanted to run another test on a vulnerability that didn’t have that limitation.
We were recently doing some basic security checks over WordPress security plugins and identified a possible issue in the plugin Total Security. While the issue we first were looking into turned out to not be exploitable, we noticed a couple of other security vulnerabilities in the plugin. The first being a persistent cross-site scripting (XSS) vulnerability. The second vulnerability allows anyone to change the plugin’s settings.
We were recently doing some basic security checks over WordPress security plugins and identified a possible issue in the plugin Total Security. While the issue we first were looking into turn out to not be exploitable, we noticed a couple of other security vulnerabilities in the plugin. The first one is a persistent cross-site scripting (XSS) vulnerability that is in the 404 log feature, which is disabled by default, due to lack of proper handling of user input data.