/PLAYBOOK · 2026-07-31

WPScan in Practice: WordPress Vulnerability Scanning Guide

WPScan hands-on guide: four-axis vulnerability scanning of WordPress core, plugins, themes, and users; WPVulnDB matching and result interpretation; includes API Token setup, rescan verification, and FAQ.

Applicable Scenarios

WPScan in practice is for WordPress site admins and security ops. It automates vulnerability scanning of WordPress core, themes, plugins, and user accounts. After suspected compromise, before an upgrade, or during periodic inspection, WPScan lists known CVEs and weak configs for installed components in minutes. It is the standard WordPress security scanner.

Prerequisites

Local Ruby 2.7+ and gem package manager
Target authorization: scan only WordPress sites you own or have written permission for
Register a WPScan API Token (free at wpscan.com) to unlock vulnerability database queries

How It Works

WPScan is fingerprinting plus version matching. It identifies the target three ways: first, default WordPress paths (e.g. /wp-json/, /readme.html) for core version; second, theme and plugin readme.txt files for component names and versions; third, enumeration endpoints (e.g. author archives /?author=1) for usernames. Once versions are known, WPScan matches them against the local vulnerability database (WPVulnDB, enabled by API Token). Hits emit the corresponding CVE and fix advice. Attack-surface enumeration plus DB matching gives a fast checkup without touching business data.

Procedure

1. Install WPScan

`gem install wpscan
wpscan --version`

On Linux you can also use the distro package: apt install wpscan (preinstalled on Kali).

2. Basic Vulnerability Scan

Replace API_TOKEN with the token from registration. Run a full core + component scan:

`wpscan --url https://helixcyber.ai --api-token API_TOKEN \
  --enumerate vp,vt,u --plugins-detection aggressive`

Flags: enumerate vp enumerates vulnerable plugins only, vt vulnerable themes, u users; plugins-detection aggressive forces deep plugin-list probing.

3. Interpreting Scan Results

`[+] WordPress version 6.4.3 identified
[!] Title: WordPress < 6.4.3 - Authenticated (Admin+) RCE
    Fixed in: 6.4.3
[+] WordPress theme in use: twentytwentyfour - v1.0
[!] No version vulnerabilities identified
[i] User(s) Identified:
[+] admin
[+] editor01`

Focus on [!] vulnerability entries and Fixed in versions. Upgrade those components first.

4. User Enumeration and Weak Password Checks

`# Enumerate users only (prep for social engineering and weak-password checks)
wpscan --url https://helixcyber.ai --enumerate u
# Password spray against enumerated users (use with care; watch rate limits)
wpscan --url https://helixcyber.ai --passwords top-passwords.txt \
  --usernames admin --max-threads 5`

Weak-password tests must stay in authorization scope. Cap threads so you do not trip WAF bans.

Configuration Verification

`# 1. Run a full scan on your own test site; confirm output includes core version, theme, plugins, and users
# 2. Cross-check WPVulnDB: visit wpscan.com/vulnerability and manually verify CVEs in the scan report
# 3. Rescan: after upgrading vulnerable plugins, rerun the same command; corresponding [!] entries should disappear
# 4. Log check: inspect the target access.log and confirm probe requests such as /readme.txt and /?author=1`

FAQ

Q1: "Scan Aborted: no WPVulnDB data" — what now?

No API Token, or the token is invalid; the vuln DB did not load. Register at wpscan.com, copy the Token, and add --api-token. You can still enumerate without the DB (--enumerate u,vp still identifies components and users).

Q2: No vulns found — is the site safe?

No. WPScan is a known-vulnerability scanner. It will not find business-logic bugs or 0days. Component camouflage (deleted readme.txt, hidden versions) can also skew results. Use WPScan as an inspection baseline; cross-check with log audit, file integrity (wp verify-checksums), and WAF logs.

Summary

WPScan fingerprints and matches WPVulnDB to give WordPress a four-axis checkup: core, plugins, themes, users. Fold it into monthly inspection: register an API Token, keep a baseline report, rescan after upgrades. Know the boundary — known vulns only. Business-layer security still needs manual testing and code review.