WordPress Vulnerability Scanning: What a CVE Feed Actually Tells You
A plugin with a published, known vulnerability sitting on a client’s site isn’t a hypothetical risk β it’s a documented weakness that anyone can look up, and automated attacks specifically search for sites running the exact vulnerable version. WordPress vulnerability scanning exists to tell you that before an attacker finds it first, which only works if you understand what a CVE feed is actually telling you and what it isn’t.
Table of contents
- What a CVE actually is
- Why version matching is the whole game
- Free vs. paid CVE sources, and a real trade-off between them
- What “virtual patch” actually means
- What to actually do with a vulnerability finding
- FAQ
What a CVE actually is
A CVE (Common Vulnerabilities and Exposures) is a publicly documented, uniquely identified security flaw β in this context, one found in a specific WordPress plugin, theme, or core version. Once published, a CVE is public information anyone can search, which cuts both ways: it lets a scanner warn you proactively, and it also means an attacker doesn’t need to discover anything themselves β they can simply search for sites still running the affected version.
Why version matching is the whole game
Most CVEs only affect a specific version range β “Plugin X, versions 2.0 through 2.4,” for example, with the fix shipping in 2.5. A useful scanner has to compare your actual installed version against that range, not just flag every site that has the plugin installed at all. WP Warden’s vulnerability scanning does real semantic version comparison against the affected range on its default free data source, so a site already updated past the vulnerable version correctly shows as not affected rather than triggering a false alarm every time that plugin’s name appears anywhere in a CVE database.
Free vs. paid CVE sources, and a real trade-off between them
The default, free data source runs a daily scan with accurate version-range matching, as described above. An optional paid upgrade to a dedicated vulnerability intelligence provider adds faster-moving, more frequently updated data β but it’s worth knowing the trade-off honestly rather than assuming “paid” is strictly more precise in every dimension: that path’s plugin-to-CVE matching works by plugin slug rather than confirmed version range, meaning any site with the plugin installed at all can surface a match, independent of whether your specific installed version is actually the vulnerable one. Faster, broader awareness and precise version-scoped confirmation are two different strengths β worth treating a paid-source finding as a prompt to check your actual version, not as confirmation you’re affected.
What “virtual patch” actually means
“Virtual patch” is a term worth understanding precisely rather than assuming it means active blocking happening on your behalf. When it appears on a finding, it’s a status label passed through from the vulnerability data provider indicating that provider offers (or has already deployed, if you use their protection product directly) a rule that mitigates the issue without needing the plugin itself updated. On its own, seeing this label doesn’t mean anything is actively intercepting the exploit for you β it’s informational context about the vulnerability’s broader protection landscape, not a description of code running on your site. The vulnerability itself, and its real severity, doesn’t change because a virtual patch exists somewhere; updating the actual plugin remains the real fix.
What to actually do with a vulnerability finding
- Update first, always. If a fixed version exists, updating past the vulnerable range resolves the finding directly and permanently.
- If there’s no fix yet, weigh disabling the plugin against the functionality you’d lose β a genuinely critical, unpatched vulnerability sometimes means temporarily living without a feature until a fix ships.
- Check severity, not just presence. A low-severity CVE on a rarely-used admin-only feature is a different priority than a critical, remotely-exploitable one on a plugin touching every page request.
FAQ
Is vulnerability scanning the same thing as malware detection?
No β they answer different questions. Vulnerability scanning tells you a plugin has a known, publicly documented weakness before anyone has necessarily exploited it on your site. Malware detection looks for evidence that a site has already been compromised. A clean malware scan and an active vulnerability finding can both be true on the same site at the same time.
How often does the vulnerability data actually update?
The free default source refreshes daily. A paid upgrade path syncs more frequently, which matters most in the narrow window right after a CVE is first published β that’s when un-updated sites are most exposed and most actively targeted.
What should I do if there’s no fixed version available yet?
Weigh the vulnerability’s real severity against what the plugin does for the site. For anything genuinely critical with no fix in sight, temporarily deactivating the plugin is a reasonable trade-off until a patched version ships β a lost feature is recoverable; a compromised site often isn’t, cleanly.
Start a free 14-day trial and know which of your sites are actually exposed, not just which ones need updates.