To monitor WordPress plugin vulnerabilities across many sites, you need three things: a current vulnerability feed, an inventory of what every site actually has installed, and a way to match one against the other on a schedule. A single-site scanner cannot answer the question that matters to an agency, which is not “is this site vulnerable” but “which of my two hundred sites are running the plugin that was disclosed this morning, and what version clears it.”
Roughly forty thousand vulnerabilities have been published against WordPress plugins and themes. Most are found in code that thousands of sites run, and most are fixed in a release that shipped before you heard about the problem. The gap between a fix existing and a fix being installed is where nearly every compromised WordPress site lives, and at fleet scale that gap is an inventory problem, not a security-research problem.
Scanning one site is not monitoring a fleet
Most tools that describe themselves as a WordPress vulnerability scanner check one site, on demand, from the outside. That is useful when you are auditing a single install. It is close to useless when you maintain fifty client sites, for three reasons.
- It is a snapshot, not a watch. A site that scanned clean on Tuesday is vulnerable on Wednesday because a disclosure happened, not because anything on the site changed.
- It answers per site, not per plugin. When a popular form plugin is disclosed, the question is which sites have it and which versions, and that is one query across the fleet, not fifty separate scans.
- It reads from outside. External scanners guess at versions from public fingerprints. The site itself knows exactly what is installed, including plugins that are inactive but still on disk, and still exploitable if a file is reachable.
What an agency actually needs is closer to inventory management: keep an accurate list of what every site runs, keep a current list of what is known to be broken, and compute the intersection on a schedule.
Where vulnerability data comes from
You do not need to find vulnerabilities yourself. Several organisations publish them, and the good tools all consume one or more of these feeds:
- Wordfence Intelligence, Defiant’s vulnerability database, which is free to query and free to use commercially. Records carry a CVSS score, a CVE where one is assigned, the affected version ranges and the patched versions.
- Patchstack, which runs a large researcher programme and powers the vulnerability data in several management tools.
- WPScan, now part of Automattic, whose database is long-established and whose API has a free tier.
- The CVE and NVD records themselves, which are authoritative but poorly mapped to WordPress plugin slugs on their own.
The data is not the hard part, and it is not where tools differ. What differs is whether you are made to pay for it per site, and whether you have to go and get an API key yourself.
Why the usual options run out
If you have tried to add vulnerability monitoring to a fleet, you have probably hit one of these walls.
Per-site pricing. ManageWP charges for vulnerability protection as an add-on at roughly $2 per site per month. WP Umbrella and Modular DS both include vulnerability monitoring on every plan, which is genuinely good, but both price per site, so the bill grows with the fleet. At fifty sites, a two-dollar add-on is $1,200 a year for one feature.
Bring your own API key. MainWP’s Vulnerability Checker is free, and works from its own NVD feed or from a WPScan API token you supply. That is a fair deal, but the WPScan free tier allows 25 API requests a day. A fleet of forty sites with thirty plugins each does not fit in 25 requests a day, so in practice you are choosing between partial coverage and a paid plan.
Nothing at all. The most common option, in practice, is a Slack channel where somebody posts a disclosure and everyone hopes it does not affect a client.
What good vulnerability monitoring shows you
Detection is the easy half. A list of every advisory ever published against a plugin is technically accurate and practically useless, because it reads like a catastrophe when it is really one update. The presentation has to answer the three questions you will actually ask:
- How bad is it? Severity, from the CVSS rating, so you can triage. Critical and high get fixed today, medium gets scheduled, informational gets ignored on purpose.
- Where is it? Every site running the affected software, at which version, and whether the plugin is even active.
- What clears it? Not the fix for one advisory, but the single version that clears every advisory affecting that site. A plugin with a dozen open advisories still only needs one update, and naming the lowest patched version would send you to a release that is still vulnerable to the rest.
If a tool tells you a site has fourteen vulnerabilities without telling you that one update fixes all fourteen, it has made your job harder, not easier.
How Siteward does it
Siteward added fleet vulnerability monitoring in v0.10, and it is free, on unlimited sites, with no API key to obtain and no account to create anywhere.
The mechanics are worth explaining because they determine the privacy properties. Siteward publishes a distilled vulnerability feed, built from the Wordfence Intelligence database, currently covering just under 39,000 vulnerability records across roughly 16,000 plugins and 2,100 themes. Your dashboard downloads that public feed on a schedule, the same feed every other dashboard downloads, and then does the matching locally against the inventory it already collects from your sites.
That means nothing about your sites is ever transmitted. The request that fetches the feed carries no identifier, no site list and no plugin list. A vulnerability scanner that sends your installed-plugin inventory to a vendor is the normal arrangement in this category, and it is worth noticing that it does not have to be.
On the Vulnerabilities screen you get findings grouped two ways: by plugin or theme, which is how remediation actually gets done, and by site, which is how you answer a client asking about their own install. Each affected site appears once, with the version it runs, the version to move to, and the advisory detail collapsed behind a chevron so the page opens as a work list rather than a wall of red. Sites carrying something exploitable also get a “Known vulnerability” flag on the overview, so an exposed site stands out without you opening the screen at all.
A workflow that actually holds
Monitoring only helps if it turns into action. A routine that works for most agencies:
- Triage by severity, not by count. Sort by critical and high. A fleet with 250 findings usually has fewer than ten that need attention this week.
- Fix by plugin, not by site. One plugin across thirty sites is one decision and one bulk update, not thirty tickets.
- Watch for the unfixable. Some advisories have no released patch, often in abandoned plugins. Those need a replacement or removal, not an update, and no amount of updating will clear them.
- Deal with inactive plugins. An inactive plugin is still files on disk. If it is vulnerable and nobody needs it, delete it rather than leaving it deactivated.
- Check that backups are current before a mass update, which is the boring half of the same job. Our WordPress security checklist for agencies covers the rest of the routine.
The short version
Vulnerability monitoring at fleet scale is an inventory problem with a data feed attached. The feed is free, from several reputable sources. The inventory is something your management dashboard already has. There is no good reason for the combination to cost per site, and no good reason for your plugin list to leave your server to make it work.
Siteward’s version is free on unlimited sites, needs no API key, and ships in the free plugin on WordPress.org. See the full feature list, the changelog for what landed in v0.10, or how it compares with MainWP.
Start free with unlimited sites See all features
Common questions
How do I check WordPress plugins for vulnerabilities across multiple sites?
You need an accurate inventory of what every site has installed and a current vulnerability feed, matched against each other on a schedule. A single-site scanner cannot do this, because it produces a snapshot per site rather than a fleet-wide answer to 'which of my sites run the plugin disclosed this morning'. A management dashboard already holds the inventory, so the practical approach is to add a vulnerability feed to it. In Siteward this is built in and free on unlimited sites.
What is a WordPress vulnerability scanner, and is it enough?
A vulnerability scanner checks one site, usually on demand and often from the outside, and reports known issues in its plugins, themes and core version. It is useful for auditing a single install. It is not enough for an agency, because it is a snapshot rather than a watch, it answers per site rather than per plugin, and external scanners have to guess at versions from public fingerprints rather than reading what is actually installed, including inactive plugins still sitting on disk.
Do I need a WPScan API key to monitor plugin vulnerabilities?
Not necessarily. Some tools, including MainWP's Vulnerability Checker, can use a WPScan API token you supply, and WPScan's free tier allows 25 API requests per day, which does not cover a fleet of any size. Other tools use their own feed instead. Siteward requires no API key and no account: the dashboard downloads a public vulnerability feed and does the matching locally.
Is WordPress vulnerability monitoring free?
It can be. The underlying vulnerability data is published free by several organisations, including Wordfence Intelligence, which is free for commercial use. Whether you pay depends on the tool: ManageWP charges roughly $2 per site per month for vulnerability protection, WP Umbrella and Modular DS include it on per-site paid plans, and Siteward includes it free on unlimited sites in its WordPress.org plugin.
Does vulnerability monitoring send my plugin list to a third party?
In most tools, yes, because matching happens on the vendor's server. It does not have to work that way. Siteward downloads the same public vulnerability feed every other dashboard downloads, carrying no identifier and no site data, and then matches it against your inventory locally, so nothing about your sites is transmitted anywhere.
Which version should I update a vulnerable plugin to?
The version that clears every advisory affecting that install, which is the highest patched version among them, not the fix for any single advisory. A plugin carrying a dozen open advisories still only needs one update, but updating to the lowest patched version leaves it vulnerable to the rest. Siteward computes this and shows one target version per site.
See it on your own sites.
Monitor unlimited sites free, or add Pro when you want expiry alerts, dynamic tags and integrations.