Something that has been coming up a lot lately is the issue of abandoned WordPress plugins and themes. Since around 30% of security vulnerabilities reported in plugins won’t get patched, people have been reaching out to Patchstack for help.
It’s a tough situation. The options are limited – you can either hardcode a fix by yourself, delete the plugin from the website or risk the security of your website and hope that the developer becomes active again.
The best approach to this problem is to try avoid such situations before they happen. Luckily, it’s something that is quite easy to avoid and only takes few minutes of due diligence everyone should do before installing a new plugin to their website.
Why are abandoned plugins dangerous?
Abandoned projects are essentially a ticking bomb. While they might be still working as intended, the compatibility and security issues are creeping behind the corner. Once a security or compatibility issue has been found, you’re essentially left alone with nobody to address it.
Making matters worse, hackers are known to target projects that are on the brink of becoming abandoned. The recent XZ utils backdoor is a great example. The original developer was struggling to keep the project updated and someone with a malicious intent offered help. Once gaining control over the project, the hacker injected a hidden backdoor into the project.
This is a great example why it’s important to keep an eye on how the developer is doing. In fact – we could even say that supporting the developers of the open source projects you’re using contribute directly to the security of your application.
Make sure the developer is known and active
Take a look at who is behind the plugin or a theme you’re looking to install. Is the company/person behind the plugin disclosed in a transparent way? Is there a simple way to reach out to them?
If the plugin is hosted at WordPress plugin repository, take a quick look at the details and see when was the project last updated. This gives a good indication of whether the it’s in active development.
Next up, open up the “Support” page and see if the developer is engaged with the users and is answering questions. Keep in mind that some projects have their main support channel elsewhere (such as live chat on website), so if the WordPress plugin repository support page is empty, try to validate if their support exists elsewhere (and if it’s responsive).
Look at the frequency of past updates
Take a look the frequency of past updates. In the WordPress plugin repository, navigate to the “Development” page and click on the “Development log”. This will show you the dates of all previous updates.
If a project has received a recent update, but has not been updated for a year before that – this could indicate that the project has not been a priority for the developer or the project could have even changed its ownership. The latter is very important to double check, so you know who the new owner is.
Look at the history of known security issues
The most common reason how people find out that the plugin they are using is abandoned is after a security vulnerability has been left unfixed. In many of those cases, WordPress plugin repository also closes the plugin, to avoid people from downloading it (unfortunately, affected users are not being notified).
Security fixes should be prioritised by the developers, as they often require immediate attention. It’s the ultimate test to see how responsive a developer is, so in case the project has any known CVE’s – take a look at how much time it took for them to release a fixed version.
The best sign is when the vulnerability is being disclosed on the exact same day when a patched version is released. This shows that the developer is a) responsive and deals with the security issues as priority b) that the developer is coordinating the vulnerability disclosure with the reporter.
Bonus tip: Take a look if the project change-log also describes the security fix and if the developer released a blog post or sent out any public communication. Some developers unfortunately try to hide such information which can result with some of the users not knowing to prioritise it as a security update. This actually becomes illegal by law in coming years.
Conclusion
The best way to reduce risk that may come from abandoned projects, is to prevent using such in the first place. You can also do your part by supporting the developers of the projects you’re using. The security of the open source ecosystem really is in our hands.
Some additional resources:
Join the Conversation!
There's a dedicated thread on this post inside of The Admin Bar community. Join in on the conversation, ask questions, and learn more!
Group Thread