WordPress Allowing Plugins With Known Vulnerabilities To Return To The Plugin Directory
Two weeks ago we discussed the need for fixes for vulnerabilities in WordPress plugins to tested, using an example of a plugin that had a vulnerability that was disclosed in 2012 that had not actually been fixed. That plugin has now been removed from the Plugin Directory due to our reporting to the people running it that the issue remained and that there was another security vulnerability was in the plugin. While WordPress badly needs to finally start notifying when a website already has a plugin with known vulnerabilities installed, stopping others from adding the plugins while they know it to be insecure is a lot better than nothing. But a couple of recent vulnerabilities we reviewed show that WordPress is allowing plugins that have been removed from the Plugin Directory to return without the vulnerabilities being fixed.
The first case involves the SP Project & Document Manager plugin, which was found by Michael Helwig to have a several security vulnerabilities. The advisory indicated that WordPress security team had been aware of the vulnerabilities and that the vulnerabilities had been fixed in version 2.6.0.0. When we went to test out the vulnerabilities to add them to our service we found that what we considered to be the most serious vulnerability had not been fixed as of the then current version, 2.6.1.2. That vulnerability allowed anyone who was at least a subscriber level user the ability to upload any kind of file, so for example they could upload a .php file and execute code on the website through that.
This vulnerability is quite easy test for, all you have to do is:
- Installed and activate the plugin.
- Create a new post with the [sp-client-document-manager] in it.
- Visit the new post (preferably while log in as subscriber level user).
- Attempt to upload .php file.
After doing that you would see the file has been successfully uploaded.:
So we have hard time understanding how it was the WordPress folks could have missed it that it had not actually been fixed.
The second case involves a persistent cross-site scripting (XSS) vulnerability in the DW Question & Answer plugin, which was discovered by Rahul Pratap Singh. The advisory indicated that WordPress security team had removed the plugin several days before a new version was released, 1.4.2.3, that patched the vulnerability. When we went to test out the vulnerability to add it to our service we found that the vulnerability had not been fixed as of the then current version, 1.4.2.3.
In this case it would have been more complicated for the WordPress security team to check if the vulnerability had been fixed since the proof of concept provided with advisory was not very good. But looking at the changes made in version 1.4.2.3 should had given them pause that it probably had not been fixed, since we don’t see anything that looks like it should had fixed the claimed issue.
WPScan Vulnerability Database Fails As Well
In these both of these cases you had the plugin’s developer, the discoverer of the vulnerability, and the WordPress people all aware of a vulnerability, but it still remained in the plugin. If you used our service you would have been warned as soon as we had reviewed the vulnerabilities and we also made sure that vulnerabilities actually got fixed, but what about similar services? Last week we reviewed one plugin and found that it didn’t warn about these vulnerabilities or any of from the last month. But what about if used one of the plugins that gets it data from the WPScan Vulnerability Database? You would have been out of luck as well, in both cases they improperly list the vulnerabilities as been fixed in earlier versions: