With the recent Freemius vulnerability affecting over 7 million WordPress users, there have been a number of inconsistent reports that have alarmed developers and users alike. These inconsistencies underscore the need for broader understanding of security vulnerability reporting.
It is my hope with this article to add clarity to how vulnerability reporting works. As users of open source software, we all have a greater responsibility for the security of our sites, which requires some baseline understanding of how security reporting works. My hope is that everyone in the WordPress space working with open source software is a little more informed about security vulnerability reporting so that we all can make better decisions about software.
What is Freemius and what happened
Freemius is a software development kit (SDK) and is the most popular managed eCommerce platform for selling WordPress plugins and themes. It offers functionality for plugin and theme developers to easily offer a path from free-to-paid, right within the plugin or theme that you are using. As such, its code is used within many popular themes & plugins. According to Patchstack, over 1,000 plugins and many themes use Freemius.
With news of this vulnerability hitting the WordPress security space, some WordPress site owners received messages from their hosting provider that some plugins that were not vulnerable were in fact vulnerable. Some vulnerability scanners were reporting that some plugins were not patched with a recommendation to remove that plugin, even though that plugin no longer used Freemius or the plugin had been patched.
With so many plugins using (or previously using) Freemius, WordPress vulnerability reporting became… a complicated thing.
Conversations in various Slack instances where plugin developers and security researchers collaborate were frenzied as data was shared and corrections were made.
I don’t envy those who maintain vulnerability databases or those who alert users. It’s a lot of work.
At the moment, this experience is underscoring how important understanding this process and procedure is for anyone working with open source software. Some of the following information might be overkill and more than you need to know, but it will at least give you a look into how detailed and rigorous security vulnerability research is, and how much effort goes into this reporting.
How Vulnerability Reporting Works
When a security researcher finds a vulnerability in a WordPress plugin or theme, they have a number of methods of handling the report. They can report directly to the developer, they can work with a CVE Numbering Authority, or they can report to the WordPress security team to assist in handling disclosure, patching and verification of the patch.
All of this is done via secure and private channels to ensure that news of a vulnerability is not disclosed prior to a fix being implemented. Once a secure communication channel with the responsible developer is established, a security researcher will share their “proof of concept” detailing the discovered vulnerability and how it could be exploited.
Disclosure of an unpatched vulnerability publicly is frowned upon and can be extraordinarily damaging to those using that software. These types of public disclosure are known as zero-day vulnerabilities (0days), and allow malicious attackers to exploit those vulnerabilities.
Upon completion of the disclosure process, the developer will patch the software and often send the patch back to the security researcher to test and verify that the discovered vulnerability is patched. Once done, the developer will release the patched software, often with a minor nondescript note in the software changelog to indicate that the software contains a security patch.
Once the software patch is widely adopted, the security researcher will obtain a CVE (Common Vulnerabilities and Exposures) number to identify the vulnerability from a CVE Numbering Authority (CNA). In so doing, this number clearly delineates the vulnerability being patched so that those who manage software can track and manage software updates to keep their systems protected. The CNA often maintains a database of these vulnerabilities in coordination with the MITRE Corporation, a non profit managing the CVE Program to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. MITRE manages CVEs and registers CNAs. All of the CNA’s reporting on WordPress vulnerabilities are a part of MITRE’s program.
When a CVE is assigned, the vulnerability is also assessed a score with the Common Vulnerability Scoring System (CVSS). CVSS scores are calculated using a formula consisting of vulnerability-based metrics. Scores range from 0 to 10, with 0 representing no severity and 10 representing critical.
Supply Chain Impacts
In the case of the Freemius vulnerability, this one vulnerability had a much wider impact because it is (and was) used by so many other software packages. These types of vulnerabilities are often called “supply chain” vulnerabilities. The software developer you purchased from didn’t have the vulnerability, but the software they use in their supply of software components did.
It’s hard. It’s complex. But as a WordPress user in the open source space, your freedoms mean you have a certain level of responsibility to understand how the WordPress site you own is impacted by the developers whose code you trust.
Software, especially open source software, is predicated on trust. You decide which developers you’d like to trust with your data and your digital home on the web, and so ensuring that there are timely patches for vulnerabilities and transparent communications from those developers is a big part of your vetting process for deciding which software package, whether a theme or plugin, you would like to use.
It’s a big job.
Help is out there
Luckily, you’re not alone. We have a number of organizations in this space who are working to assist. No matter who you’re getting your vulnerability reporting from, I firmly know and believe that they all are doing their best to ensure data is updated quickly.
It requires a ton of due diligence to maintain accurate data so that users are not erroneously alerted, and that they are properly alerted, when there is a serious vulnerability requiring immediate attention.
Inaccurate reporting, whether missing vulnerabilities or reporting that a vulnerability exists when it doesn’t, can erode trust in the reporting mechanism or create alert fatigue so that users don’t pay attention to. Ensuring that reporting is done accurately, rapidly, and with relevant severity ensures that users know what is affected and what action to take.
But that information needs to be accurate and timely.
Who has the authority?
There are numerous security vendors that run weekly or monthly vulnerability reports, however there are just a few organizations that maintain actual vulnerability databases. These organizations often share information. As registered CNAs through Mitre, they are both able to assign CVE numbers, as well as report on CVEs assigned by other CNAs.
Those organizations that do not have their own databases rely on the integrity of those who do.
Sounds complicated. Sort of?
For most software genres, there is a singular CNA that is authorized to assign CVEs. For WordPress, with nearly 60,000 plugins and numerous themes, there are 3 CNAs: WPScan, Patchstack, and Wordfence. These are the sources for any of the vulnerability reporting you receive. Some organizations get their data from WPScan, owned by Automattic. Some organizations get their data from Patchstack, such as the iThemes weekly vulnerability report.
Some have wondered whether or not there is a lack of authority. Contrarily, there are a number of authorities. And I don’t envy any of them.
With approximately 60,000 plugins in the WordPress repository, some of which are using various SDKs like Freemius, tracking vulnerability impact is daunting.
Should this get fixed? Is there a problem?
I don’t think so, and I think all of the organizations maintaining this data are doing their best. This type of tracking and disclosure can be a challenge.
Having friends and colleagues in all areas of vulnerability reporting and security research, I know that everyone is doing their best.
Values and focus
Of course, we’re all here for one core purpose: to make it easier for our users to understand the software in their websites and make it easier to discern what actions need to be taken. As long as we remain true to those values of serving our users, it all works out.
There were definitely some gaps in this reporting, but usually I find that these folks step up quickly to be as accurate as possible.
In doing my part, as I’m merely an overly interested spectator at this point, I am here to provide some context so that understanding vulnerability reporting is a tad easier.
What you can do
My advice for WordPress site owners is below.
- Patch early, patch often. Watch your software changelogs for indications of security patches and apply those quickly.
- Know your software developers. Like I said, software is about trust, and trust means having a relationship. If you’re really into a software framework like Kadence, get to know that team and ensure you’re on the mailing list.
- Be wary of non-transparent communication. If a software package doesn’t fully disclose security issues or passes things off as unimportant, be wary.
- Uninstall software (plugins, themes) that you’re not actively using.
- Be aware of the CNAs in the WordPress space and follow at least one of them for updates. I am personally quite impressed with the diligence of the Patchstack team and highly recommend following their work. (Not an affiliate link.)
- Pay attention to vulnerability reporting. Once you get the feel for how CVEs and CVSS work, you’ll know when it’s a drop everything and patch versus I’ll patch that next update cycle.
- Hire an expert. If you’re looking for someone to help you get a handle on open source security, find an expert who can help. I do some consulting with organizations managing numerous WordPress sites and can assist if needed.
- Be grateful to security researchers. I know that a lot of developers hate to hear from their friendly neighborhood researcher. But they truly are trying to do right by you and your users. Think of them as an asset, be thankful, and reward responsible disclosure by working with them to ensure security bugs are squashed.
- Don’t sweat the vulnerabilities. Code vulnerabilities are simply “celebrity bugs” that have a little more notoriety. If you’re a developer, be honest and open about bugs to your users goes a long way towards solidifying relationships with your fans and user base.
