In March 2024, WordPress 6.5 introduced a feature called plugin dependencies. As you may know, there are many plugins which are essentially add-ons for other plugins. The plugin dependencies feature of WordPress core aims to make the process of installing and activating such add-ons (dependents) and the plugins they rely on (dependencies) consistent and easy.
This is a great time to talk about the security risk of plugin dependencies and software supply chain. When we look at the past few years, the most widespread security vulnerabilities found in plugins have been introduced by dependencies inside plugins which have rendered thousands of other plugins vulnerable.
This has also happened to the WordPress core in the past. As WordPress core is dependent to jQuery library, then any vulnerability found in jQuery itself may transfer over to the WordPress core and have significant impact on the security of the entire WordPress ecosystem.
Software supply chain visibility in WordPress ecosystem is limited
This is a problem that is yet to be solved. The plugin dependencies feature released in WordPress 6.5 is more about usability than security and just looks at wether Plugin A requires Plugin B to be installed and so on.
There’s currently no standards or a way to see what kind of third-party libraries and software packages are being shipped within plugins. The only way to check wether a plugin comes with third-party dependencies is to do code review.
To give you an example of how deep the rabbit hole can get, here’s a dependency graph of the WordPress core and Elementor. These examples also show how hard it is to accurately detect what code is actually being shipped vs just being mentioned.
What makes matters worse, is the fact that many of these dependencies have also their own dependencies. For as long as we don’t have full transparency, tracking and standards in place to know what kind of dependencies are being shipped with WordPress plugins/themes, it’s difficult to react in time to down-stream security issues.
There’s a thing called SBOM (software bill of materials), which is essentially a list of ingredients for software. It’s quickly becoming a standard in the security and open source software ecosystem and hopefully we’ll see WordPress adopt this as well (and require all plugin authors to do the same).
How does this affect the security of a WordPress website?
The worst vulnerabilities are the ones we don’t know about, but hackers do. This is what can easily happen when there’s no visibility over the dependencies. If you don’t know what software you’re running, then you also don’t know if it has any vulnerabilities that you need to patch.
Even if you have the visibility (let’s say you do code-review for everything you use), you still rely on the dependency developer and a plugin developer to get the official patches. Before you can install a patch on your website, you need to wait for the dependency developer to make a patch available for your plugin developer and depending on the number of parties involved – this could take quite a long time.
At Patchstack, we’ve helped multiple plugin developers to navigate this complex scenario. When a XSS vulnerability was found in Freemius SDK last year, it affected more than a thousand different plugins, which then affected millions of websites. Freemius did a great job to release the patch as fast as possible and communicated the importance of this release to their users, but the websites which were affected still needed to wait for the individual plugins to release an updated with the fixed SDK.
In this entire process, due to no standards and visibility, we had to scan the entire WordPress plugins repository to detect which plugins and themes (and which versions) had the vulnerable Freemius SDK code present. Without all that work, it would have been impossible for website owners to know that they even are vulnerable at all.
Conclusion
You can’t protect against what you don’t know about, so knowledge is everything. One of the biggest security challenges WordPress ecosystem will be facing in coming years is the transparency of the software supply chain. We need to agree on standards which everyone should follow.
What can you do? Ask your plugin vendors for SBOM, do they even know what code they ship? If we want the ecosystem to become more secure, then we need to demand it.
Resources:
WordPress Plugin Dependencies feature: https://make.wordpress.org/core/2024/03/05/introducing-plugin-dependencies-in-wordpress-6-5/
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
Oliver Sild
Oliver Sild is the CEO and Co-founder of Patchstack. He is an entrepreneur and cyber security expert with a strong focus on community building. He has been organising hacking competitions (& local CTF community) in Estonia since 2016, has kickstarted a startup community in his hometown and has nearly 10 years of experience with WordPress security.
