Skip to content
ThemesIonic — home
Plugins

WPScan

WPScan checks what you are running against a database of known WordPress vulnerabilities. It answers one narrow question extremely well, and mistaking it for general security tooling is the usual error.

4 min read advanced

WPScan answers one question: does anything I am running have a known, published vulnerability? It maintains a database of WordPress core, plugin and theme vulnerabilities, and compares it against what your site has installed.

That is a narrow question and a genuinely valuable one, because the overwhelming majority of compromised WordPress sites are compromised through a known issue in an outdated component — not through anything novel.

What it is, in its several forms

  • A vulnerability database, which is the actual product. Everything else is an interface to it.
  • A command-line scanner, which examines a site from the outside and reports what it can identify.
  • A WordPress plugin, which runs inside the site, reads the installed versions directly, and reports matches by email.
  • An API, with a free daily allowance, which is how tooling queries the database.

The plugin is the right choice for most site owners: it knows exactly what is installed rather than inferring it, so its report has no guesswork in it. The CLI is for people auditing sites they do not administer from the inside.

Enumeration is not the useful part

The scanner can enumerate users, plugins and themes from outside a site, and this attracts more attention than it deserves.

Two reasons to care less about it than people do:

  1. Hiding your version numbers is not security. An attacker's scan does not need to identify your plugin version — it can simply try the exploit. Obscurity raises the noise floor and stops nothing.
  2. The valuable output is the vulnerability match, not the inventory. Knowing you run a plugin is uninteresting. Knowing that version has a published authenticated privilege escalation is actionable.

So do not spend effort blocking enumeration and consider the site secured. Spend it on the update discipline that closes the actual holes.

Where it fits

WPScan is one item on a list, and it is not the first:

Priority Measure Why
1 Keep everything updated Closes the vulnerabilities WPScan reports
2 Two-factor authentication Defeats the attack that actually succeeds
3 Remove unused plugins and themes Deactivated code is still on disk
4 Off-site backups Recovery when prevention fails
5 WPScan or equivalent monitoring Tells you when 1 has slipped
6 A firewall Buys time between disclosure and patch

Its real job is catching the gap between a vulnerability being published and you applying the update — which on a site with automatic updates disabled can be months. The wider list is the WordPress security checklist, and the plugin category comparison is in security plugins.

Using the plugin sensibly

  • Schedule a regular scan and send the report somewhere a person reads.
  • Act on findings promptly. A report nobody acts on is worse than no report, because it creates a false sense of coverage.
  • Update on staging first where the site matters, following updating plugins safely.
  • When a vulnerable plugin has no fix, the answer is to remove it rather than wait. An abandoned plugin with a published vulnerability is not going to be patched.
  • Delete rather than deactivate. Deactivated plugin files are still on disk and still reachable in some vulnerability classes — how to delete a plugin completely.

What it will not tell you

Being clear about the boundary:

  • It does not detect a compromise. It reports known vulnerabilities in known components, not that someone is already inside. If you suspect that, the process is how to fix a hacked WordPress site.
  • It does not find vulnerabilities in your own code, or in a custom theme nobody has published research on.
  • It does not cover configuration mistakes — weak passwords, a world-writable directory, exposed credentials in a file.
  • It does not stop anything. It reports.

Authorisation

Scan sites you own or have written permission to test. This is not a formality: running a scanner against a third-party site without authorisation is unwelcome at best and unlawful in many jurisdictions, and intent is not a defence. If you audit client sites, get it in the engagement terms.

Common mistakes

  • Treating it as protection rather than as reporting.
  • Reports going to an unmonitored address.
  • Blocking enumeration and considering the job done.
  • Leaving a vulnerable but deactivated plugin installed.
  • Waiting for a fix on an abandoned plugin instead of replacing it.
  • Scanning without permission.

In practice

Install it, schedule it weekly, send the report to a real inbox, and commit to acting within a defined window — days, not months. That commitment is what turns a scanner into a control. Without it, WPScan is a very good source of information about a site nobody is going to update.

Frequently asked

No. It reports which of your installed components have known published vulnerabilities. Acting on that report — updating, replacing or removing the component — is what protects the site.
For the vulnerability data, yes. The scanner can enumerate what is installed without one, but the useful part — matching versions against known issues — comes from the database, which is accessed with a token that has a free daily allowance.
Scan sites you own or have written permission to test. Running a scanner against someone else's site without authorisation is at best unwelcome and in many jurisdictions unlawful, regardless of intent.
Tagged Security

Related guides