On this page (7 sections)
On August 24, 2026, Patchstack published a case study saying its vulnerability protection add-on inside the ManageWP dashboard blocked more than 11.9 million threats in six months. This is not a new vulnerability or an incident. It is a vendor-authored marketing piece, and it is the only source we have for this story.
It is still worth a look if you run WordPress for clients, because it touches two real problems: the gap between a vulnerability becoming public and a patch reaching your sites, and how to manage that gap across many sites at once.
What the case study says
According to Patchstack's case study, Patchstack has powered ManageWP's Vulnerability Protection since February 2026 as an add-on inside the ManageWP dashboard. The article describes three things the add-on does:
- It shows vulnerability exposure for every client site in a single view.
- It applies mitigation rules automatically to protected sites once a vulnerability is identified, before a patch exists or clears review.
- It requires no code changes and no per-site logins.
The headline number, 11.9M+ blocked threats over six months, comes from Patchstack. The piece does not say how a threat is counted, how many sites were covered, or how many of those events were real exploitation attempts rather than scanning noise. Treat the figure as a marketing statistic, not a measure of how many sites would have been compromised.
The problem it is aimed at
The case study makes two claims about the wider landscape, both from Patchstack: attackers weaponize the most-targeted vulnerabilities in a median of five hours, and nearly half of vulnerabilities have no update available at the moment they become public. We could not check these against a second source, so read them as the vendor's framing.
It also mentions WordPress.org's "Protect the Shire" policy, which Patchstack says has been live since June 2026 and adds up to a 24-hour hold on every plugin and theme release before it reaches sites. We have no independent confirmation of the policy details, so check WordPress.org's own announcements before planning around that delay.
What virtual patching can and cannot do
The approach described is commonly called virtual patching: a rule blocks the request pattern that exploits a known flaw, so a site stays protected while the real fix is pending. It is useful, but it has limits worth understanding before you rely on it.
| Aspect | Mitigation rule | Real update |
|---|---|---|
| Fixes the code | No, blocks known attack patterns | Yes |
| Available before a patch exists | Often, if a rule is written | No |
| Covers every variant | Not guaranteed | Yes, if the fix is complete |
| Needs ongoing maintenance | Rules must keep pace with new flaws | Update each release |
Who is realistically exposed
The risk this story points at is highest for agencies and freelancers who maintain many sites on different plugin sets, where one popular plugin flaw becomes a portfolio-wide task. Single-site owners face the same gap, just at smaller scale. Abandoned plugins, premium plugins without a clear update channel, and sites updated only monthly are the usual weak spots.
What to do now
You do not need ManageWP or Patchstack to act on the lesson. Start with an inventory, because you cannot protect what you cannot list. This WP-CLI command lists installed plugins with their status and version; run it from the site's WordPress directory and look for outdated or inactive entries.
wp plugin list --fields=name,status,version,update,update_versionThen check core and themes the same way. Both commands are read-only: the first reports whether a WordPress core update is available, and the second lists themes with their versions and pending updates.
wp core check-update
wp theme list --fields=name,status,version,update0 of 7 done
Detection and monitoring afterwards
Protection layers are one part of the picture. You also want to notice when something changes. Watch for unexpected admin accounts, modified plugin files, new scheduled tasks and unusual outbound requests. Outside-in scans can catch visible signs such as injected scripts, and certificate, DNS and uptime monitoring catch other kinds of change; see what outside-in malware detection can and cannot see for the limits. The free website malware scanner is a quick first check, and the WordPress security checklist covers the basics in order.
Bottom line
The case study is a vendor reporting its own results through a partner, so its numbers are claims rather than audited findings. The underlying advice holds regardless: know what runs on your sites, update quickly, and treat any mitigation layer as a supplement to patching rather than a replacement.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.