For the last two years, the results of the Patchstack open-source bounty program have been growing fast. In January alone, we've received 418 valid vulnerability reports. We crossed the mark of 1K valid vulnerability reports this year at the beginning of April and then added over 1000 vulnerabilities in July alone, so you can imagine the numbers we are expecting by the end of the year.
Such a high number of vulnerability reports can paralyze any research team and create a colossal backlog. However, we've worked hard over the years to create a streamlined process and internal infrastructure to manage such a load. Unfortunately, we found a bottleneck elsewhere - slowing down the processing speed of all those reports.
The bottleneck is...
Unreachable WordPress plugin developers
Our main struggle became the communication between us and the vendors. Contacting some plugin developers and forwarding vulnerability information is one of the most challenging tasks. The bar is incredibly low, we are already happy if we can find the contact email because it's common that there are no contact details at all - zero.
But, the thing is that contact information doesn't guarantee you'll be able to contact the vendor either. You'd be surprised how many domain names previously used by the vendors are dropped and on sale by third parties, how many contact forms need to be fixed, or mailboxes that are not accepting the emails because they are overloaded.
Since we follow strict responsible disclosure guidelines, this bottleneck creates the conditions for the appearance and accumulation of undisclosed and unpatched vulnerabilities. However, we must disclose vulnerabilities after 30 days once we notified or attempted to notify the vendor about the issue (unless they ask for an extension) since we have obligations to the ethical hackers who have been reporting these vulnerabilities to us.
Disclosures can help to get vulnerabilities fixed
Once we publish a vulnerability to the Patchstack WordPress vulnerability database, we still notify vendors that they have 48 hours before that entry will be publicly listed on our database - and that helps. Sometimes. Whenever we can't contact the plugin or theme owner, we try to notify the repository owner where the plugin or theme is hosted. And here things get interesting (scary).
As we checked our data, we noticed some worrying numbers. We had 404 vulnerabilities on our database that were disclosed, but not patched. These are all hosted in the wordpress.org plugins repository. This situation creates a significant risk for the WordPress community, and we decided to take action. Since these developers have been unreachable, we sent the full list of those 404 vulnerabilities to the plugin review team for processing.
We regularly communicate with the WordPress plugins review team, but we have usually only reached out to them about the most challenging cases when there were no ways to contact the vendors. With these 404 vulnerabilities, we hoped to get a response from the vendors, but it didn't happen.
More than 70% of the plugins were closed
When we send the full vulnerability reports to the WordPress plugins review team, some plugins will be updated, and some will be closed - forever. Out of those 404 vulnerabilities, more than 70% remain closed. This begs a question for those developers. Why keep those plugins "alive" if you're not maintaining or supporting them?
Vendors and developers should act more responsively with the software they publish, even when we are talking about open-source software, yes, it is distributed with a license that says you use the software at your own risk, but there's no reason to make that risk higher through neglect and carelessness.
You could notify the users that you've discontinued the project or try to find a new owner, but as long as there are users who rely on that, you should not abandon them and keep them in the dark. You also have the option to remove your software from the repository.
Follow the good examples
Recently we had a great example of how to manage abandoned software. One of our researchers found a vulnerability in the old plugin developed by Joost de Valk. Once we contacted Joost, he acted in an exemplary manner.
He released the patched version of the plugin, notified the users on the changelog and social media about the patch release, and that the plugin is not supported anymore and will be removed from the repository after some time. Also, he mentioned that every current user should look for alternative software. Great solution and excellent communication.
Plugin developers should set up a vulnerability disclosure program
Maintaining the software is challenging, and understanding the security reports can sometimes be difficult. That's why we launched the Patchstack mVDP (managed vulnerability disclosure program) project.
To help the community, we created a 100% free (no strings attached) tool for WordPress vendors and developers that eliminates such communication bottlenecks and provides an easy way for every project to have its own VDP (vulnerability disclosure program). It doesn't matter where you host your WordPress software, whether it is free or premium - the mVDP program is free and available to everyone.
Moreover, it's more than just free. The Patchstack Alliance project backs it - the only public WordPress-focused bounty program that covers all free and premium plugins and themes. It will offload some of the pressure from the WordPress plugins review team and make the patching and vulnerability processing easier for all involved parties.
The entire WordPress ecosystem should take action
The WordPress plugins review team is a small group of volunteers, and we have all heard about the backlog that they need to deal with. Each plugin developer who becomes unreachable and does not take action on the security reports increases that backlog.
The goal is simple - to make the WordPress ecosystem safer. Everyone in the community benefits from this, and if we act individually, then it's a pretty easy goal to reach. We just need everyone to be involved, especially vendors and developers. Let's start with the tiny steps - review your contact information, create a VDP program for every plugin you have, and add the necessary contact details to your plugin readme.txt and/or SECURITY.md files.
Please also keep in mind that currently, WordPress Core does not even show if an installed plugin is removed from the repository for security reasons. If it's vulnerable and unfixed - the core just shows that it's properly up to date. We need to change that, so please support that change here: https://core.trac.wordpress.org/ticket/30465
Conclusion
Is 404 the final number? No! We are preparing more similar lists for the wordpress.org themes repository and repositories focused on premium products. We are currently processing about an extra 200+ similar vulnerabilities.
In the end, here are the stats
- 404 vulnerabilities
- 358 plugins affected
- 289 plugins (71,53%) - Closed
- 109 plugins (26,98%) - Patched
- 6 plugins (1,49%) - Not closed / Not patched
- Up to 1.6 million active installs affected
- Average installs per plugin 4984
- Highest install count 100000 (two plugins)
- Highest CVSS 9.1
- Average CVSS 5.8
- "Oldest" plugin - 13 years since the last update
