The WP Super Cache Vulnerability That Wasn’t a Vulnerability
In March, Search Engine Journal wrote a story about a “vulnerability” the very popular WordPress plugin WP Super Cache, which has 2+ million installs. The issue was described this way:
A flaw was disclosed today that exposes users of WP Super Cache to an authenticated remote code execution (RCE) vulnerability.
Remote code Execution is an exploit that allows an attacker to take advantage of a flaw that can let them upload and run malicious code.
The usual intent is to upload and execute PHP code that then allows them to do things like install backdoors, access and make changes to the database and attain administrator level control of the site.
Once an attacker has administrator level control the site is effectively under their control.
There was important detail missing in that, as the author noted:
What level of registration is needed depends on the exact vulnerability and can vary.
Sometimes it needs to be a registered user with editing privileges. In the worst case scenario all the attacker needs is the lowest registration level such as a subscriber level.
No details have been published as to which kind of authentication is needed for the exploit.
So what level of user would the attacker need to have to get access to the equivalent capabilities that the highest level WordPress role, Administrator? The level was Administrator. No, you are not reading that wrong, the attacker would have to be an Administrator to exploit the “vulnerability”, which would provide them the equivalent of the role they already have. So that isn’t a vulnerability at all.
If you don’t believe us, here is the original report. To “exploit” this you have to have access to the plugin’s settings page, which is restricted to users with the manage_options capability, which only Administrators have:
240 | add_submenu_page( 'settings.php', 'WP Super Cache', 'WP Super Cache', 'manage_options', 'wpsupercache', 'wp_cache_manager' ); |
PatchStack Red Team and WPScan Spreading False Report
While this obviously not a vulnerability, a couple of our competitors who tout how many vulnerabilities to their data sets without any concern for the accuracy of their data both were spreading this false report.
One of them Patchstack, claimed that the original reporter is part of their Patchstack Red Team:
They also claimed it has a severity of 7.2 out of 10.
The other claimed they verified this, despite the proof of concept they provided not working:
