As promised in the v6.3 announcement, WP Toolkit is back again with another major release. With v6.4 we introduce to you, Vulnerability Protection, and more! Let’s go over the changes in detail together.
Vulnerability Protection: Safeguarding Your WordPress Sites
Our new WP Guardian offering finally comes to WP Toolkit, bringing vulnerability protection for WordPress sites. This is a huge change for WordPress security and there’s a lot to unpack here. What is vulnerability protection? How does it work? What problems it aims to solve? Why it’s important?
Addressing Key Challenges:
-
New Vulnerabilities: When new vulnerabilities rear their heads, WordPress domains are at their most fragile, with fixes often lagging behind. Vulnerability protection ensures site security during this critical period.
-
Abandoned Sites: Neglected domains, left to languish or abandoned, present a menace to server and domain integrity. Vulnerability protection erects barriers against such domains metamorphosing into potential threats to the entire server.
How Does It Work:
Protection is a service continuously working in the background, like an antivirus or a firewall. Enabling protection on a site installs a small worker plugin inside your WordPress. This plugin monitors your WordPress assets (plugins, themes, and WordPress core), constantly checking if they have any dangerous vulnerabilities. When such vulnerability is found, the plugin automatically downloads and applies special protection rules that prevent this vulnerability from being exploited on the site. After vulnerable asset is updated and vulnerability is removed by the update, protection rules are unapplied automatically.
This approach ensures minimal performance overhead, as protection rules (also known as virtual patches) are very small and they’re applied surgically, only for those vulnerabilities which are actually present on a site. Moreover, since these protection rules work similar to firewall rules, they do not modify or change the site code itself in any way, ensuring its integrity.
To Recap, vulnerability protection is:
- Automated: Protection works continuously and automatically, protecting the site from current and future vulnerabilities without user involvement.
- Non-invasive: Protection rules work like a firewall, so they never modify the site code.
-
Lightweight: Protection rules are applied only for specific vulnerabilities present on a given site, so they have minimal effect on site performance. (Premium feature)
Does it work on all vulnerabilities?
Vulnerability protection only neutralizes high and medium risk vulnerabilities. If you see a vulnerability that isn’t neutralized yet, it means one of the following:
- Work in progress. Rules for high-risk vulnerabilities are usually made available within hours of vulnerability disclosure. Rules for medium risk vulnerabilities might take days to be created due to lower impact.
- Low risk. Some vulnerabilities have minimal impact on a site or lack real exploit methods. Since they do not present a real threat to websites, protection rules for them are not necessary (or, in some cases, plain impossible to verify).
-
Missing in database. Vulnerability protection is powered by technology provided by our security partners from Patchstack, so it works with vulnerabilities in Patchstack database. Vulnerabilities that are present only in Wordfence database or not matched with corresponding entries from Patchstack database do not receive protection rules. We’re working on matching all possible duplicates between two databases, but it will take us some time, since there are thousands of entries to be matched.
How do I get this feature?
Vulnerability protection (also known as virtual patching) is a part of the WP Guardian platform. It requires purchasing a separate license called WP Guardian (cPanel addon).
How do I control who gets this feature?
Packages in WHM now include a separate limit for the number of sites that can use vulnerability protection. This limit is set to zero by default to make sure resellers and customers cannot see this feature unless server administrator wants them to. In other words, only server administrators are able to see this feature and its purchase prompts out of the box. If you want to disable this feature completely (so that even server admin can’t see it), or if you’d like to configure the upsell links presented in WHM part of WP Toolkit, do the following:
* Navigate to manage2.cpanel.net and log in,
* Select Update Company Information and scroll down to the Sales Option section
* Change Purchase WP Guardian (cPanel Addon) item to Custom Store (which will prompt you to specify your own store URL) or Do Not Sell (which will completely hide the feature).
We hope that vulnerability protection feature will make millions of WordPress websites managed by WP Toolkit safer, contributing to the overall health of the WordPress ecosystem.
Risk Rank and Vulnerability Filtering: Streamlining Vulnerability Management
You might remember that WP Toolkit v6.3 has introduced the integration with Wordfence database. Now site admins around the world could see even more vulnerabilities on their websites! But do you know what’s better than seeing more vulnerabilities on your sites? Feeling the magical bliss from not seeing any pointless ones:
The image above is what site admins will see in v6.4 after installing a fresh copy of WordPress.
Wordfence database has introduced a number of vulnerabilities in WordPress core unlikely to ever be fixed by the WordPress team. These vulnerabilities are low-risk, theoretical, not-likely-to-be-exploited-ever, and so on. In other words, they were not important enough to really care about, and they weren’t getting a fix any time soon — but since they were present, site admins got vulnerability warnings on basically all WordPress sites without being able to do anything about it. This made vulnerability alerts pointless, since people were quickly getting alert fatigue. There was no way to differentiate between things you should take care of (dangerous or exploited vulnerabilities) and things you could simply ignore (like these low-risk WordPress core vulnerabilities), so people started to just ignore everything. This needed to be fixed, the sooner the better, and we did just that.
So, what did we do and how did we do it?
WP Toolkit v6.3 has also introduced the vulnerability filtering feature. It utilized a user-provided CVSS score threshold to hide vulnerabilities below the specified score. The main problem was that CVSS rating used for filtering vulnerabilities is difficult to understand for non-tech users (“what number I’m supposed to use as a threshold?“) and, without going into details, it’s not always accurately reflecting the actual severity of WordPress-specific vulnerabilities. We’ve set out to replace CVSS with our own internal Risk rank that’s calculated based on CVSS, EPSS, Patchstack Patch Priority and some other markers.
Our Risk rank does a much better job at reflecting the actual severity of WordPress vulnerabilities, so we’ve switched the filtering from CVSS to Risk rank. We have also enabled this filtering by default, meaning that all vulnerabilities with “low” risk rank will be hidden and ignored after the upgrade to WP Toolkit v6.4. This is how it looks now:
This solution gives a better out-of-the-box experience (no more warnings that your WordPress is vulnerable on a fresh install), doesn’t annoy users, retains the value of Wordfence database where it’s actually needed (there are some genuine vulnerabilities only present in the Wordfence database at the moment), and leaves the control in the hands of users. And yes, we’ve checked and confirmed that all these “annoying, low-score, won’t be fixed” WordPress core vulnerabilities reported by Wordfence will be correctly filtered out, so unless end-users explicitly disable the filtering, it should be smooth sailing with no distractions from that moment on.
Preinstallation of WordPress & Sets on cPanel: Simplifying Site Provisioning
All cPanel packages now have a package extension with WP Toolkit option for preinstalling a WordPress site when the account with this package is created. Another option allows to choose which set should be automatically installed together with WordPress. This set will be installed every time a new WordPress site is installed under the corresponding account.
Disclaimer: This feature fully works when used via GUI, but it might have limited availability via API for now. We’re working on making it available via API as soon as possible.
Bug fixes & Improvements: Ensuring a Smooth Experience
WP Toolkit Version 6.4 also includes numerous bug fixes and enhancements borne out of user feedback, enhancing overall product stability and performance.
The Road Ahead
Our next stop on the road ahead is working on improving the performance of WP Toolkit, together with several bugfixes, long-requested features, and further improvements for the upcoming updates. Stay tuned.
