This article is brought to you by Wordfence, a WordPress security firewall we encourage all WordPress website owners to install.
Abandoned Plugins
At Wordfence, we define a potential abandoned plugin as one that has not been updated by its developers in at least 2 years. In May, we analyzed the plugins in the WordPress.org repo and found that almost half of them hadn’t been updated in over 2 years. Over a third of them had a compatibility tag for a WordPress version dating back to 2014 or earlier.
The alert we send tells you how long it’s been since the developer updated the plugin, as well as whether we found reference to any unpatched security issues with it and whether it has been tested with the current version of WordPress.
Why Should You Care if a Plugin Hasn’t Been Updated Recently?
If a developer hasn’t updated a plugin in two or more years, there is a really good chance that the plugin author has actually abandoned the plugin altogether. An author that has abandoned a plugin is very unlikely to fix any security vulnerabilities that users have reported. No plugin is immune to becoming a security vulnerability on a website, even simple plugins with small user bases. Simply put, the older a plugin’s code, the higher the risk of security issues.
Let’s look at ways that vulnerabilities happen or are discovered:
1. Many Plugins Use Software Components That Were Written by Someone Else
One of our favorite examples is the TimThumb vulnerability that was discovered in 2011 by someone we know quite well here at Wordfence. TimThumb was an image-sizing utility that was included in lots of themes and plugins. Once the WordPress community discovered the vulnerability, all of the theme and plugin authors who had used it had to scramble to release a fix of their own for each of their plugins.
In the case of an abandoned plugin, the authors wouldn’t likely be available apply a quick fix. To this day, we continue to see attacks seeking to exploit this very old vulnerability on sites that we protect.
2. WordPress Plugins Function in a Very Dynamic Environment
WordPress.org publishes core WordPress updates constantly, and PHP, Apache, Nginx and updates to other plugins and themes are posted at least as often, too. This continually changing landscape represents a security risk over time.
A great example is the ‘add_query_arg()’ and ‘remove_query_arg()’ issue that GoDaddy/Sucuri discovered two years ago. The issue here was with a WordPress function that plugin and theme developers use to interact with WordPress core. To fix the issue, each plugin developer needed to update their code and push updates. Any plugin author who was no longer paying attention would likely miss this and leave the vulnerabilities in their code.
3. Security Researchers and Attackers Are Constantly Finding Vulnerabilities
As of this writing, the WPVulndb website has publicly reported five WordPress plugin vulnerabilities in the last week alone.
When a security researcher discovers a vulnerability, they reach out to the developer, disclose the details and give them a fixed amount of time to release a fix. Once the author releases the fix, the researcher generally publishes their findings publicly.
However, in cases where the author does not respond, such as with an abandoned plugin, the researcher will sometimes release the details anyway, giving attackers the information they need to exploit it. The worst case scenario is when an attacker is the first to discover a vulnerability, leaving literally all of the sites running that plugin vulnerable to attack before developers get the chance to release a fix.
What Should You Do if One of Your Plugins Appears to be Abandoned?
The best option in this situation is to remove the plugin and replace it with a plugin whose author is actively maintaining the code. If a suitable replacement doesn’t exist and you are a software developer, or know someone who is, it might be possible to assess the risk and potentially decide to maintain it yourself going forward if vulnerabilities are reported.
Plugins Removed from WordPress.org
Plugins listed in the WordPress.org plugin directory need to follow a set of guidelines. The list of requirements is long, so there are a wide variety of reasons why the WordPress.org team may remove a plugin.
One common security reason is that a security researcher has discovered a vulnerability, contacted the author without getting a response, and then contacted the WordPress plugin team about the author’s unresponsiveness. The WordPress plugin team will do their best to contact the author, but if they also receive no response, they will subsequently remove the plugin from the plugin directory.
It’s important to stress that not all of the reasons for removing a plugin represent something that should lead you to stop using the plugin, but many of those reasons are worth taking into consideration when deciding whether to keep a plugin on your website.
What Should You Do if the WordPress.org Directory Removes One of Your Site’s Plugins?
Your first course of action should be to try to determine why it was removed. If you’re able to verify that the plugin was removed for a non-security reason, then it might be okay to continue to use it. It’s a judgement call on your part based on all the information you’re able to gather. If you can’t figure out why it was removed, or you confirm that it was removed due to a security vulnerability that hasn’t been fixed, we recommend that you remove the plugin from your website immediately and finding a well-maintained replacement for its functionality.
Conclusion
As we’ve written about in the past, vulnerable plugins are the most common way that attackers compromise WordPress websites. It is critical that, as a site owner, you only install (and keep) reputable plugins on your website, and that you keep them up-to-date and remove them if they are abandoned. The new alerts that we added last week should make that task much easier going forward.
