State of WordPress Security In 2022

In 2022 we saw 328% more security bugs reported in WordPress plugins – we added 4,528 confirmed security bugs to our database, compared to 1,382 in 2021.

The vast majority of the security bugs were found in plugins (93%). Themes accounted for 6.7% of bugs and only 0.6% were in the WordPress core platform itself.

This doesn’t mean that WordPress is unsafe, or that plugin developers are getting sloppier - rather, the security researchers are looking harder and farther.

This also means that the WordPress ecosystem is becoming more secure because a lot more of these security bugs are being addressed and patched.

In previous years Cross-Site Scripting (XSS) has been the most common security bug reported, but in 2022 it was narrowly edged out by Cross-site Request Forgery (CSRF).

CSRF made a huge jump – when in 2021 it made up 11% of reported bugs, then last year it was 29%. There are a couple of reasons for that.

Firstly, CSRF is generally easier to find and thus they are reported more often. Secondly, last year a CSRF bug was found in the Freemius framework which affected a large number of plugins. Consequently, the number of CSRF bugs also increased dramatically.

Not all bugs are created equal – how big of a risk they pose depends on many different factors. Based on these each verified security bug is assigned a CVSS score on a scale of 10, with 10 representing critical severity.

These were the most popular plugins containing a security bug, defined as having at least 1 million installs and at least one bug.

Only five of the plugins contained a high severity bug, and none contained a critical one.

Two of the highest CVSS score vulnerabilities were found in plugins related to Elementor. In 2022 we found security bugs in four other page builders. Most page builders are premium plugins and thus harder to access for security auditing, which explains the relatively small number of security bugs reported in them.

However we’d like to emphasise that even if you’re using page builders to develop sites, you should still be mindful of the tools you use, and perform regular updates.

We analyzed our firewall activity logs to detect which vulnerabilities attackers target the most. The following is a ranking of the vulnerabilities based on how many exploit attempts were made against them.

We also keep seeing attack attempts against older vulnerabilities.

There are open-source hacking tools available online which are made to automate attacks on scale. Many of them are made years ago and include exploits of known old vulnerabilities.

In general, however, few old vulnerabilities get active exploit attempts – over time sites update or remove vulnerable plugins, which in turn makes it harder for the attacker to find a website that can be exploited. For an attacker this may not be worth it if the success rate starts dropping significantly.

The WordPress core team published 4 security releases in the project in 2022. These four releases addressed 26 security bugs in total, the most severe of which was a framework security enhancement.

The patch for aforementioned CVE-2022-21661 (Described as improper sanitization in WP_Query) protects plugin developers from creating SQL injection bugs, by ensuring all data is properly sanitized before it reaches the database.

When we looked at the most critical security bugs disclosed in 2022, we found that 26% never received a fix.

Most of the time abandoned and unsupported plugins are removed from the WordPress.org directory - but any such plugins that are installed on websites will stay there until deleted by people running those sites.

We have talked about the risks of using abandoned plugins and themes before. Such plugins are dangerous because they are a potential threat even if the site has auto-updates enabled. A vulnerable and abandoned plugin would give no indication to the user that something is wrong - with no available updates it would look as if everything were up to date.

Furthermore, if a plugin is removed from the WordPress plugin repository, the public record of its security issues is lost.

Security bugs are just bugs that can be patched. A security bug becomes a vulnerability if a site does not receive a patch. If that vulnerability is exploited it leads to sites being compromised. Notifications about insecure components inform users to patch, preventing the compromise from happening.

The majority of bugs reported through the Patchstack Alliance in 2022 received a timely patch from the developer. However, not all reports lead to patches. In some cases, the insecure component received no patch and was subsequently removed from its respective repository. The closure of 87 themes/plugins in 2022 was directly related to their inability to address a security bug.

An unfortunate truth is that software available in public repositories is sometimes unsupported due to it being abandoned. This problem is exacerbated by the fact website owners will see a misleading "no update available" for these insecure components. Many site owners are simply unaware they are running insecure and unsupported components.

Using a vulnerability assessment tool like the Patchstack app or Patchstack Threat Intelligence feed can help identify components with known security bugs in them, empowering site owners to take action to secure their sites before they are hacked.

The global economy and open-source software have something in common. They both depend on a supply chain – the past year showed many of us what happens when supply chains break down. How life can be disrupted when individual links in these ephemeral chains are unsupported or fail, the outcomes can be unexpected.

Open source depends on a supply chain of code. We first saw the effects of security bugs in the open-source software supply chain in late 2021 with a vulnerability in log4j. This concern is not limited to just Java-based logging libraries though. In 2022 the WordPress ecosystem experienced vulnerabilities in multiple component supply chains, but it fared a lot better than log4j. Here is what happened and why.

Freemius is a popular SDK (Software Development Kit) used by hundreds of popular WordPress plugins and themes. In early 2022, there was a report of a low to medium-risk security bug found in the Freemius code. This spurred a monumental effort from the Freemius team and WordPress.org plugin repository volunteers. The almost thousand plugins that utilized Freemius needed to be informed to update their version of the Freemius libraries in their code base.

The good news was hundreds of plugins that were notified of the security bug in Freemius updated their project's code and patched the bug. The bad news was dozens to hundreds of projects did not respond to the notifications. These projects did not update their Freemius libraries, and in the end, were removed from the WordPress.org repository due to security concerns.

A fully independent platform that sells plugins for WooCommerce shops, also independently develops all of its offered plugins using its own in-house framework. This central framework is a mature development practice, which lead to a smooth rollout when they faced a security bug.

A single, low to medium-severity security bug (CSRF) was identified in the shared code between many of the YITH plugins. The developers at YITH produced a patch in short order and deployed this patch downstream to dozens of their affected plugins.

The patch made available downstream was much faster for YITH compared to Freemius. This is because the Freemius library is used by many developers, while YITH's code libraries were only used in their own plugins. This a sign that security improves with fewer links in the overall software supply chain.

These examples have one common positive thing going for them. Each project was supported by its developers, and those developers were able to make a security patch available for all of the projects downstream that relied on their core code or framework.

If you run or manage a WordPress website, it is important to know what plugins and themes you rely on. The next time you apply a security patch, remember that the patch was made available by a developer somewhere upstream in your supply chain. Take a minute to acknowledge your reliance on their support and consider supporting those projects in turn.

Over the past year or so we’ve seen a very positive trend of more and more WordPress hosting services alerting their customers about vulnerabilities in their sites.

We’ve been working together with service providers to integrate our vulnerability feed to their systems in an effort to create an additional security layer for the WordPress ecosystem. A notable example of this is One.com – in one year they fixed 56,000 vulnerabilities on their customers’ sites with the help of our intel feed and their own update management software.

Since late 2021, 17 hosting & service providers have started using our threat intelligence feed to alert their customers. We want to extend our thanks to all of them for making the ecosystem safer:

Open-source security is a community effort.

Patchstack Alliance is our bug bounty platform that helps connect security researchers with plugin developers. Our goal is to make it easier for researchers to submit vulnerability reports to developers, and for developers to have an easier time managing security issues.

Since creating the Alliance in 2021, we’ve grown our annual number of confirmed vulnerability reports more than seven times.

In 2022 we paid $16,050 in bounties to ethical hackers for valid bug reports. Our researchers reported 748 unique security bugs.

710 CVE IDs were reserved for those vulnerabilities – the number is smaller than the number of vulnerabilities reported due to some reports being merged upon inspection.

Whenever our researchers find a security bug, we first try to reach out to the developer of the plugin or theme and get them to resolve the security issue. Unfortunately, this is not always possible, and if the developer is unresponsive, we notify the WordPress team about the security bug.

In 2022 we asked the WordPress team to get involved in 147 cases. Of these, 60 bugs were subsequently patched by their developer.

The plugin with the largest installation base that we could not contact had over 800,000+ active installations. The developers patched the security bug only after the WordPress.org team notified them about it.

Of the 60 plugins that were escalated to the WordPress.org team, 31 had more than 10,000+ installs.

However, 87 security bugs went unpatched even after escalation. These projects were likely abandoned and have been removed from the WordPress.org repository.

We encourage all plugin developers to be more open about security issues, and we recommend you have a vulnerability disclosure policy in place to make reporting security bugs easier. If you have stopped actively supporting a project, then you should let your users know.

Having a transparent approach to security is a sign of a mature approach to development, and it can be a trust signal for your users.