← All security check guides

Check a WordPress site for known vulnerabilities

WordPress runs a huge share of the web, which makes it the most targeted CMS there is. The danger is rarely exotic. It is usually a core version, plugin, or theme left a few updates behind, each carrying flaws that are public, catalogued, and automated against within days.

What a fail costs

CheckWeb detects the WordPress core version from what a page reveals, then counts the CVEs that actually affect that version, per version rather than the lifetime total, using the NVD advisory ranges. One live site scanned recently ran a core old enough to carry 158 known CVEs at Critical severity.

This is a weight-2 fail on the Security axis (35% of the overall score), on par with vulnerable front-end libraries. An outdated core is not a yellow warning. It is the loudest single signal that a site sits one automated scan away from trouble.

Passive and safe

This is a passive check. CheckWeb reads only what a site shows any visitor: the version fingerprint, the libraries a page loads, the response headers, the TLS certificate. It never probes wp-admin, never sends payloads, never tests logins. That is why anyone can safely scan any WordPress site.

The deeper, active checks (exposed backups, open admin panels, an exposed `.git` or `.env`) run only on a domain proven to belong to the person requesting them. CheckWeb detects from the outside and never breaks in.

How it looks in the report

Under the Security axis, the report shows a line reading "CMS known vulnerabilities" with a red FAIL status and evidence naming the detected core and its per-version CVE count: for example WordPress 3.7.1 with 158 known CVEs at Critical severity. Alongside it sit "Vulnerable front-end libraries" for anything a plugin or theme bundles, plus the security headers and TLS status. Together they form the passive picture of how exposed a site is right now.

Example

CMS known vulnerabilities

WordPress 3.7.1: 158 known CVEs (max Critical)

FAIL

Exposed vs hardened

Exposed

A core several majors behind (for example 5.x while 6.x is current), with plugins not updated in a year.

Hardened

A current core, plugins and themes on their latest release, and a version fingerprint that is not broadcast.

How to fix it

  • Update the core to the latest release. This alone clears the largest CVE count.
  • Update every plugin and theme, since that is where most bundled vulnerable libraries hide. Remove the ones that go unused.
  • Stop broadcasting the version (the `?ver=` query string and the generator tag), so the site is not advertising exactly which CVEs apply.
  • Add the core security headers most themes omit. (See the security headers check.)
  • Keep auto-updates on for minor releases, then re-scan to confirm the Security axis recovered.

Check a WordPress site now

Paste a WordPress site's URL for the passive picture in seconds: core CVEs by version, vulnerable libraries, headers, and TLS. No signup, no login, nothing sent to the site.

Check my website

FAQ

Is it safe to scan a WordPress site?
Yes. The scan is passive: it reads only what the site shows any visitor, such as the version fingerprint, loaded libraries, response headers, and the TLS certificate. It never probes wp-admin, sends payloads, or tests logins, so scanning cannot affect the site.
Does the scan check plugins and themes?
The passive scan detects vulnerable front-end libraries that a plugin or theme bundles into the page, and flags an outdated core with known CVEs. Enumerating every installed plugin needs active probing, which runs only on a domain verified as belonging to the requester.
How does CheckWeb count WordPress CVEs?
It detects the core version from what a page reveals, then counts only the CVEs whose affected range includes that version, using the NVD advisory ranges, with the maximum severity computed over the same set. The number reflects the running version, not the lifetime total.
Is CheckWeb free for WordPress sites?
Yes. The passive scan is free and needs no signup. Deeper active checks, such as exposed backups or open admin panels, run only on a verified domain.

Related checks