WP Toolkit has grown from a convenient installer into the main tool for keeping hundreds of WordPress sites patched on a cPanel server. The 136 release added a Security Risk score per site, a Vulnerable Components view that maps installed plugins and themes to known advisories, and moved the toolkit’s wp-cron trigger to a five-minute interval. Combined with Smart Update, which clones a site and compares it before and after an update, these features let one engineer keep a large fleet in shape. This guide assumes WP Toolkit 6.11.3 or later, which is also the build that fixed the cross-account flaw CVE-2026-87900 (see our write-up).
Table of Contents
Short answer: In WHM » Plugins » WP Toolkit, sort sites by the Security Risk label, open the Vulnerabilities tab to update, deactivate or virtually patch every component with a known advisory across all affected sites at once, and apply the bulk Secure action so the hardening checklist is enforced everywhere. For plugins likely to break on a major release, enable Smart Update so the toolkit tests the update on a clone and leaves production untouched if pages change.
Check the toolkit version and licence tier
Everything below except Smart Update and automatic vulnerability patching is available in the free WP Toolkit Lite that ships with cPanel. Smart Update and automated patching require the WP Toolkit Deluxe licence, which is included with some cPanel licence bundles and sold as an add-on otherwise. Confirm the version and tier from the shell:
wp-toolkit --info
rpm -q wp-toolkit-cpanelIf the version is older than 6.11.3, update immediately; WP Toolkit updates through the normal upcp run but can be forced with /scripts/update-packages.
Read the Security Risk score
Open WHM » Plugins » WP Toolkit. Each site row now carries a risk label (Low, Medium, High, Critical) derived from three inputs: unapplied security measures from the toolkit’s checklist, outdated WordPress core or components, and any installed component that appears in the vulnerability feed. Sort the list by risk and start at the top.
Clicking the score expands the reasons. A typical Critical is a plugin with a public RCE and no update installed; a typical High is an outdated core version plus disabled file editing not being enforced. The score is a triage aid, not a scanner, so a site with clean components but a webshell in wp-content/uploads still shows Low. Keep your malware scanner running alongside.
To pull the same data for automation:
wp-toolkit --list -format json | jq '.[] | {id, siteUrl, securityRisk}'Fix Vulnerable Components
The Vulnerabilities tab lists every plugin, theme and core version on the server that matches a known advisory, grouped by component so you can see that one plugin affects forty sites at once. For each entry you have three actions:
- Update to the fixed version across all affected sites in one operation.
- Deactivate the component if no fix exists. This is the right call for abandoned plugins with an unpatched RCE.
- Protect with a virtual patch, which pushes a WAF rule that blocks the exploit path until the customer updates. This requires the Deluxe licence and either Imunify360 or the toolkit’s own rule injection into
.htaccess.
A common pitfall is updating a plugin across all sites without checking for a major version jump. Page-builder and e-commerce plugins in particular often break sites on a major release. Use the filter to see the target version, and for those plugins run the update through Smart Update rather than the bulk action.
Roll out updates with Smart Update
Smart Update clones the site to a temporary directory, applies the update to the clone, crawls a sample of pages before and after, and compares screenshots and PHP errors. If it detects a difference above the threshold it leaves the production site untouched and shows you the diff.
Enable it per site under the site’s Updates settings, or for all sites through WP Toolkit » Settings » Updates. From the CLI:
wp-toolkit --update -instance-id 42 -smart-update yesSmart Update needs disk space for the clone (roughly the size of the site’s files, not the uploads directory) and takes a few minutes per site, so schedule fleet-wide runs overnight. If a site fails the comparison repeatedly because of dynamic content (rotating banners, date stamps), lower the sensitivity for that site or exclude the offending URL from the crawl in the site’s Smart Update settings.
Enforce the security checklist
The toolkit’s Security tab per site contains the standard hardening list: block PHP execution in wp-content/uploads, disable file editing in the dashboard, disable pingbacks, restrict access to wp-config.php and .htaccess, and turn off directory browsing. Apply the whole list to every site with the bulk Secure action, then set Settings » Security » Apply to new installations so provisioning is safe by default. These measures change the site’s .htaccess and wp-config.php, so if a customer uses a caching plugin that rewrites .htaccess, re-check after their next plugin update.
Understand the wp-cron change
Since 136, WP Toolkit disables the in-request wp-cron.php trigger on managed sites and calls it from a system cron every five minutes instead. This removes the load spike from busy sites firing cron on every page view and makes scheduled posts reliable on quiet sites. If a customer complains that a plugin’s scheduled task now runs “late”, five minutes is the maximum delay; the previous behaviour was actually less predictable. Check the interval in Settings » wp-cron, and confirm it is running with:
grep wp-toolkit /etc/cron.d/* /var/spool/cron/root 2>/dev/nullVerify
After a triage pass, filter the site list by risk and confirm no site remains at Critical. Run wp-toolkit --list -format json | jq '[.[] | select(.securityRisk=="critical")] | length' and expect zero. Open two or three of the updated sites in a browser and check the front page and the admin dashboard load without PHP notices. Finally, subscribe root or your support address to the toolkit’s vulnerability notifications under Settings » Notifications so new advisories reach you before the customers do. Fleet-wide WordPress patching is one of the services our engineers run for hosting providers who would rather not staff it.
WP Toolkit security risk score at a glance
Official documentation: WordPress advanced administration handbook, cPanel & WHM documentation, Linux man pages.
Related guides: Fix WordPress “cURL error 28: Failed to connect” caused by Imunify360 or CSF · WP Toolkit CVE-2026-87900: cross-account database writes and the 6.11.3 fix · Fix Imunify360 missing from the WHM interface (enable-plugin and other causes).
Frequently asked questions
Is Smart Update included in the free WP Toolkit Lite on cPanel?
No. Risk scores, the Vulnerable Components view and the security checklist are in WP Toolkit Lite, but Smart Update, automatic vulnerability patching and virtual patches need the WP Toolkit Deluxe licence.
Does the WP Toolkit security risk score detect malware?
No. The score is built from unapplied security measures, outdated core or components and known vulnerable components. A site with clean, current components but a webshell in wp-content/uploads still shows Low, so keep a malware scanner running alongside it.
Why do scheduled WordPress tasks run up to five minutes late since cPanel 136?
WP Toolkit disables the in-request wp-cron.php trigger on managed sites and runs it from a system cron every five minutes instead. That removes cron load from page views and makes scheduling on quiet sites reliable, with five minutes as the maximum delay.