WordPress Leaves Admins Unaware of Insecure Plugins on Their Websites

These days when WordPress gets hacked it isn’t likely to be due to a vulnerability in WordPress, it’s much more likely to be due to a plugin. Unfortunately, there hasn’t been enough focus on the security issues related to plugins and working to fix those. A glaring example of this, that we found while preparing some information for this post, is that the WP CSS plugin contained a vulnerability that had been publicly known for six months, that the vulnerability had been recently attempted to be exploited, and yet it was still being distributed in the WordPress.org Plugin Directory until last Friday.

WP CSS also highlights another failing of the current plugin security handling. It’s something that we share some of the blame for because we should have realized the issue existed long ago and we are now trying to make an amends for that by taking on the issue. The following is the process that is supposed to take place after a security vulnerability in a plugin is reported to WordPress, as we had done with WP CSS.

  1. The plugin is de-listed from the repository, to prevent further downloads of an insecure plugin.
  2. If the exploit is accidental or not obviously malicious, the developer is notified via email. The email comes from a valid address (plugins at wporg) and can be replied to.
  3. The plugin developer presumably fixes the exploit or tells us that it is an invalid exploit, updates the plugin in SVN, and emails back saying so.
  4. We check it out, and either provide advice or re-enable the plugin.

For websites that haven’t had the plugin installed yet the process protects them from the vulnerability. But the same can’t be said for all the websites that already have the plugin installed. If the vulnerability is promptly fixed then the websites should be okay as long as the plugins on the website are kept up to date. The big problem comes when plugins are either not promptly fixed or never fixed at all. In those cases websites with the plugin installed admins receive no notification in WordPress that there is a security vulnerability in the plugin or even that it has been removed the Plugin Directory. There also isn’t any indication on the WordPress Plugin Directory that the plugin was removed, instead when you go to the page where the plugin used to exist you are just told “Whoops! We couldn’t find that plugin. Maybe you were looking for one of these? ” (you can currently see an example of this with the WP CSS page).

It’s not clear why no information is provided, it seems hard to believe the people who are handling plugin security issues at WordPress would not be concerned what happens to websites who already have the plugins installed. If the idea is that hiding the issue would provide the websites with the plugins installed some protection it doesn’t make much sense and isn’t working. In many cases the vulnerabilities have been publicly released, as is the case with WP CSS. For potential attackers it is easy to find the information, but people running WordPress websites are much less likely to be looking at those things. It’s then not surprising that we are seeing attempts to exploit removed plugins. In the month of February the following 14 removed plugins were attempted to be exploited on our website:

  • 1 Flash Gallery (1-flash-gallery)
  • Category List Portfolio Page (category-list-portfolio-page)
  • Disclosure Policy Plugin (disclosure-policy-plugin)
  • DP Thumbnail (dp-thumbnail)
  • IP Logger (ip-logger)
  • is_human() (is-human)
  • jQuery Slider for Featured Content (jquery-slider-for-featured-content)
  • Kish Guest Posting (kish-guest-posting)
  • LISL Last-Image Slider (lisl-last-image-slider)
  • Really Easy Slider (really-easy-slider)
  • Rent-A-Car-Plugin (rent-a-car)
  • VK Gallery (vk-gallery)
  • WordPress News Ticker (wordpress-news-ticker-plugin)
  • WP Marketplace (wp-marketplace)

You would only need to have one of those plugins installed to have your website successfully hacked. In all of those attempts, it looks like the attempts were part of a general attempt to exploit as many websites as possible. It appears that many removed plugins contain vulnerabilities that wouldn’t be useful for this type of mass attack, but would be useful for a targeted attack on a website so the issue plugins with known vulnerabilities should be a major concern for websites that are likely to targeted for attack.

An Interim Solution

Instead of just complaining about this we have come up with an interim solution for the issue by creating a plugin that reports any installed plugins that have been removed from the WordPress.org Plugin Directory. All you have to do is to install the plugin and go the plugin’s page to see if there are any installed plugins that have been removed from the directory.Screenshot of No Longer in Directory Plugin

One obvious and reasonable question is to ask is why our plugin warns about all removed plugins instead of just the ones with security vulnerabilities. The biggest reason for doing it this way is that because WordPress doesn’t release information on why plugins were removed we don’t which ones were removed security issues. We could just limit our warning to plugins that have publicly released vulnerabilities, but that leaves the possibilities that we miss some or many more plugins. The other issues is that plugins that have been removed for other reasons are unlikely to be fixed if a security vulnerability is found after it has been removed, for some plugins it appears that this has been the case.

A limitation of the plugin is that it will only warn about plugins that have been removed as of the last time we updated the plugin list in the plugin. Our current plan is to update the full list once a month.

We are looking at the possibility of integrating information on the security vulnerabilities in removed plugins into the plugin, so that admins can make more informed decision about what to do if there are removed plugins installed in their WordPress installation.

If WordPress does make changes to Installed Plugins page to warn of removed plugins, then it would also be good to also provide the option of showing the relevant changelog entries as well so that admin are aware of when security issues have been fixed in plugins. Some plugins already have similar functionality built into them. That functionality is also available with the Changelogger plugin.

If you are looking to increase the security of your WordPress installation and you perform software updates in WordPress you should take a look at out our plugin for performing update processes using HTTPS.