A plugin you installed two years ago and have not thought about since may have a remote code execution flaw that was disclosed, assigned a CVE, and patched four months ago. The patch exists. It is sitting in the plugin repository right now. You simply have not applied it.
That gap, between "a fix is available" and "the fix is running on your site", is where most WordPress compromises happen. Vulnerability scanning is the practice of measuring that gap continuously instead of discovering it during an incident.
Most compromises are not zero-days
There is a persistent belief that getting hacked means someone found a novel flaw and used it against you specifically. For the overwhelming majority of WordPress sites, that is not what happens.
What happens is far more mundane. A researcher finds a flaw in a plugin with 40,000 installs. They report it privately. The developer ships a fix. The vulnerability is published to public feeds with the affected version range attached. Within hours, that record is being read by people who are not researchers, who then fingerprint WordPress sites at scale looking for installs still running the affected range.
The economics matter here. Nobody is spending a week studying your particular site. They are spending an afternoon writing something that tries one known exploit against a hundred thousand sites, because at that scale even a low hit rate pays. You are not a target. You are a row in a list.
This is good news, because it means the defence is unglamorous and entirely achievable: know what you are running, know what is known to be broken, and close the distance between the two.
What a vulnerability record actually contains
A useful vulnerability feed maps a plugin or theme slug to one or more records. Each record carries the pieces you need to make a decision:
- Affected version range. For example, "less than 2.4.1". This is the field that determines whether you care at all.
- Fixed version. The first release that contains the patch.
- CVE identifier. The stable public reference, so two tools discussing the same flaw agree on what they are discussing.
- CVSS score and vector. A severity number from 0 to 10, plus a breakdown of how the flaw is exploited.
- Vulnerability class. SQL injection, cross-site scripting, authentication bypass, arbitrary file upload, privilege escalation, and so on.
That last field does far more work than people give it credit for, and we will come back to why.
Where the data comes from
Several projects catalogue WordPress-specific vulnerabilities, and they do not fully agree with each other.
Wordfence Intelligence publishes a free feed with broad coverage of the plugin and theme ecosystem, including records for software that never appears in the national databases. Patchstack maintains its own catalogue with a similar focus. WPScan has long been a reference point for the same problem space. The National Vulnerability Database carries CVE records across all software, but its WordPress plugin coverage lags the specialist feeds, because a plugin with 5,000 installs rarely gets prompt attention from a general-purpose catalogue.
The practical consequence is that a scanner is only as good as the feed behind it, and a scanner reporting zero findings is telling you about its feed as much as about your site. WPMgr uses the Wordfence Intelligence feed, which is the most comprehensive free source for this ecosystem.
Version matching is harder than it looks
The naive version of this problem is a string comparison. The real version has several failure modes worth knowing about, because they explain why two scanners can look at the same site and disagree.
Version strings are not reliably sortable. WordPress plugins use everything from 1.2.3 to 2.0-beta4 to 20240115. Comparing "is 2.0-beta4 less than 2.0" correctly requires implementing the comparison rules rather than sorting alphabetically, and sorting alphabetically puts 10.0 before 9.0.
Premium plugins are frequently invisible. A paid plugin distributed from the developer's own site has no repository listing. Its slug may not match anything in the feed, and its version numbering may be entirely internal. Feeds cover many commercial plugins, but coverage is thinner than for free ones.
Forks and white-labelled copies keep the code and lose the identity. A plugin someone renamed still carries the vulnerable function, but its slug no longer matches the record.
Abandoned plugins have no fixed version at all. When a plugin is closed without a patch, the record has an affected range and nothing to upgrade to. The remediation is removal, and a tool that only knows how to offer an update button has nothing useful to say.
Backported patches break the range logic. A maintainer occasionally patches an older branch, which means a site on 1.9.7 may be safe while the record says "less than 2.4.1".
None of this makes scanning less worthwhile. It means findings deserve a moment of judgement rather than blind automation, and that "no findings" is not the same as "no risk".
How WPMgr connects the feed to your fleet
WPMgr pulls the vulnerability feed on a schedule and stores the records centrally. The agent on each site reports its installed plugins, themes, and core version as part of the regular diagnostics push, so the inventory is a fact gathered from the site rather than something you maintain by hand.
The control plane compares that inventory against the feed and surfaces matches. Each finding shows the plugin or theme name and installed version, the severity, the affected range, the fixed version, and the CVE reference.
Because the comparison happens centrally rather than on each site, adding a site does not add scanning work to that site, and a newly published record is matched against every site you run the moment the feed updates, without waiting for a per-site scan to come around again.
Triage: severity is not the same as priority
The most common mistake once you have findings is to sort by CVSS and work down the list. That is a defensible default and it is frequently wrong. Three other factors change the ordering.
Is the plugin active? A deactivated plugin's code generally does not run, which lowers urgency considerably. It does not lower it to zero: files remain on disk and some flaws are reachable in deactivated code. The correct end state for a plugin you are not using is deletion, not deactivation.
Does exploitation require authentication? A CVSS 8.8 flaw that needs a valid contributor account is a different problem from a CVSS 7.5 that any anonymous visitor can reach. On a site with open registration those converge. On a site with three known admin accounts they do not. Read the vector, not just the number.
What does the site actually hold? The same flaw on a brochure site and on a store processing card details produces very different consequences. Severity describes the flaw. Priority has to account for the blast radius.
A workable order for a fleet: anything unauthenticated and remotely exploitable on a site handling customer data, then everything else unauthenticated, then authenticated flaws on sites with open registration, then the rest.
Acting on findings without breaking things
Updating a plugin to close a vulnerability carries exactly the same risk as any other update. The fix may change behaviour your theme depends on. The safest sequence:
- Take a backup immediately before the update, not last night.
- Apply the update in staging first where one exists, particularly for anything touching checkout, forms, or membership.
- On production, run the update with automatic snapshots enabled so a failure rolls back rather than leaving a half-updated site.
- Watch the site for a short window afterwards. An update that fatals is obvious. An update that quietly breaks a contact form is not, which is why uptime monitoring that checks for content signatures rather than just a 200 response is worth having.
For a plugin that has been closed without a fix, the sequence is different: find a maintained replacement, migrate the data, then delete the plugin. Leaving it deactivated is not remediation.
What scanning does not tell you
Vulnerability scanning answers exactly one question: does anything you have installed match a known, published flaw? It is silent on everything else.
- Zero-days, by definition, are not in the feed.
- Malware already present is a different problem. If a site was compromised through a flaw you have since patched, patching does not remove what was installed in the meantime. That is what file integrity monitoring is for.
- Custom code written for your site is in no catalogue anywhere.
- Configuration weakness is invisible to it. A shared admin password is not a CVE.
- Server and PHP versions sit outside the plugin feeds even when they are the weakest link.
Scanning is one instrument. It pairs with integrity monitoring to catch what got in, two-factor authentication and login hardening to reduce the credential surface, and backups as the recovery path when something lands anyway.
Making it a cadence rather than an event
The single highest-value change most operators can make is turning this from an occasional audit into a routine that runs whether or not anyone remembers.
Review new findings on a fixed schedule rather than when you happen to log in. Treat unauthenticated critical findings as interrupt-driven work rather than queue work. Delete plugins you are not using instead of deactivating them, because every installed plugin is permanent surface area. Keep a note of anything you deliberately deferred and why, so a decision made with context is not silently inherited as neglect six months later.
Across a portfolio, the fleet view matters more than the per-site view. What you want to answer quickly is not "is this site clean" but "which of my fifty sites have outstanding critical findings right now", because that is the question that determines where the afternoon goes.
Setting it up
Connect a Wordfence Intelligence API key in the WPMgr admin area. The key is free, and the vulnerability data WPMgr reads is free. After the first sync, findings appear on each site's Security tab and in the fleet-wide vulnerabilities view.
For the wider picture of how the pieces fit together across a portfolio, see the WordPress security solution.