Free WordPress Vulnerability Scanner

What a WordPress vulnerability scanner checks, and why it matters

A WordPress vulnerability scanner looks for software with known security flaws: a plugin, theme, or the WordPress core itself running a version that has a publicly-documented vulnerability. When a flaw is published it gets a CVE identifier (Common Vulnerabilities and Exposures), and attackers immediately start scanning the whole web for sites still running the affected version. You do not have to be a target. Automated bots find vulnerable versions by the thousands.

This matters most for WordPress because the risk is overwhelmingly in the add-ons, not the core. Plugins account for roughly 96% of WordPress vulnerabilities; only a handful are ever in core (Patchstack). And the volume keeps climbing: Patchstack recorded nearly 8,000 new WordPress vulnerabilities in 2024, about a 34% rise on the year before (Patchstack, via SecurityWeek). The average small business site runs a dozen or more plugins, so the odds that at least one is behind on a security patch are high.

BadgerScan tells you, in plain English, which of your detectable versions match a known CVE, and what to do about it. To be clear up front: this is a passive scan. We read what your site already publishes and match it against vulnerability databases. We never run exploits, never penetration-test, and never touch anything we are not allowed to read.

How BadgerScan checks it

This is not a separate tool you run on its own. There is one BadgerScan, and the WordPress vulnerability check is one part of it: the same passive external scan that also covers your DNS, email security (SPF, DKIM, and DMARC), TLS certificate, HTTP security headers, and exposed files. You run it once and get everything together. Run the free scan.

On the free external scan, we detect the versions your site exposes to the public: the WordPress core version, and the plugin and theme versions that are visible in your page source, readme files, asset URLs, or version query strings. We match those detectable versions against known CVEs. The honest limit is that we can only flag what is publicly detectable. A plugin that hides its version, or one that is inactive but still installed, will not show up from the outside.

That blind spot is exactly what Pro (C$10/mo per site) closes. The Pro WordPress plugin is read-only and installs inside your site, where it reads the exact installed version of every plugin, theme, and the core, active or not, hidden version string or not. It then matches that complete inventory against the CVE data and fuses the inside and outside findings into ONE plain-English grade and ONE deduplicated fix-list. Free tells you what an attacker can see from the street; Pro reads the actual inventory in the building.

How to read your result

Each detected component shows the version we found and whether that version matches a known vulnerability. A clean result means none of your publicly-detectable versions matched a known CVE at scan time. It does not prove the site is flaw-free, because undetectable or inactive components are invisible from the outside; it means nothing vulnerable is advertised to the public.

A flagged result names the component, the version, and the nature of the known issue. Treat anything tied to a published CVE as time-sensitive: once a vulnerability is public, the patch is public too, and so is the list of who has not applied it yet. Higher-severity matches, especially anything that could allow remote code execution or authentication bypass, are the ones to fix first.

If you want certainty rather than best-effort detection, that is the gap the inside scan fills. The combined report shows both views side by side, so you can see exactly which findings only the inside scan could have caught. For the bigger picture, see inside vs outside website security scanning.

Common fixes

Most WordPress vulnerability findings come down to keeping software current and trimming what you do not use.

• Update the flagged plugin, theme, or core to the latest version. The patched release almost always resolves a known CVE directly.
• Delete plugins and themes you are not using. Inactive does not mean safe; an installed-but-deactivated plugin can still be exploited, and it is dead weight either way.
• Replace abandoned components. If a plugin has not been updated in a year or more, or has been removed from the WordPress.org directory, find a maintained alternative. It will not get a patch.
• Turn on automatic updates for low-risk plugins, and put a human eye on major updates so a breaking change does not take the site down.
• Stay current on the WordPress core too. Core flaws are rare but high-impact, and core auto-updates are safe to leave on for most sites (WordPress.org, Hardening WordPress).
• Run a fresh scan after you patch to confirm the finding has cleared, then put updates on a recurring schedule rather than waiting for the next scare.