WPScan Tutorial: Scan WordPress Plugins, Themes, Users, and Vulnerabilities

WPScan is a WordPress-aware scanner. It sends HTTP requests to fingerprint core, themes, and plugins, can enumerate usernames, and can correlate those versions with the WPScan vulnerability database when you supply an API token. This tutorial runs WPScan 4.1.0 on Kali against a loopback-only Docker WordPress lab on port 42080.

You will walk the same order you use on a real engagement: confirm the tool, stand up an authorized target, run a quiet first scan, add an API token, inventory plugins, understand detection modes, read one vulnerability block carefully, then decide what to validate next. Password guessing stays optional and last.

WPScan 4 changed the default scan so it no longer automatically walks the full plugin list. A normal --url pass focuses on WordPress version, the active theme, and security findings. Use -e p, -e ap, or -e vp when you actually want plugin discovery.

The gap most generic tutorials skip is simple: WPScan can list a plugin without printing CVEs. Vulnerability titles and fixed-in versions come from the WPScan API at scan time, not from the local fingerprint files alone.

What WPScan can and cannot tell you

WPScan answers two related questions: what WordPress components and versions are observable from the outside, and which known database records match those versions when API data is available.

It can:

• Confirm the target behaves like WordPress and report core, theme, and plugin versions when HTTP evidence exists
• Flag interesting endpoints such as xmlrpc.php, readme.html, and author archives where the site still exposes them
• Enumerate usernames that appear in feeds, author IDs, or login error messages
• Pull known vulnerability titles, fixed versions, and references from the WPScan API when a token is present

It cannot:

• Prove every reported CVE is exploitable on that exact site without further validation
• Replace a full web-application test in Burp or ZAP (business logic, authz bugs, multi-step flows)
• Invent CVE lines when you never configured an API token
• Tell you the password for an enumerated user

On a pen test, treat every [!] Title: line as a lead for validation and exploit selection, not as automatic proof of compromise. Version match is necessary context. Impact still depends on whether the vulnerable code path is reachable.

Verify the WPScan version on Kali

Kali ships WPScan in its repositories. Confirm the package before you refresh metadata or scan a target, so your notes match the tool you actually ran.

dpkg-query -W wpscan

wpscan	4.1.0-0kali1

The package line is what you paste into a report or lab checklist. Print the scanner banner if you also want the tool’s own version string:

wpscan --version 2>&1 | tail -5

                    An Automattic endeavor
                    https://automattic.com
_______________________________________________________________

Current Version: 4.1.0

4.1.0 matches the package row. If the package is missing or still on 3.x, install or upgrade with sudo apt update and sudo apt install -y wpscan, then re-check dpkg-query. Full apt options are out of scope here.

Before the first scan on a new Kali image, refresh the local fingerprint metadata WPScan uses to recognize plugins, themes, and version markers:

wpscan --update

[i] Updating the Database ...
[i] Update completed.

Update completed. means the local detection database is present. That store helps WPScan recognize components and versions. It does not download the full vulnerability catalog. CVE-style titles still need an API token later. Without this update, a scan can abort immediately with Update required when database files are missing.

Build a loopback WordPress lab

Metasploitable 2 on port 80 serves a static landing page, not WordPress, so it is a poor target for this lesson. This walkthrough uses Docker WordPress bound to loopback on port 42080 so the lab is not published on every host interface and does not collide with a local Burp listener on 8080.

You need three pieces before WPScan becomes interesting: a running WordPress site, an outdated plugin with known database records, and at least one username. The steps below build that target once; later sections only scan it.

Set the target URL and a scratch directory once so every later command reuses the same values. These exports last for the current shell only — re-run the block in a new terminal.

export WP_URL=http://127.0.0.1:42080
export LAB=/tmp/wpscan-lab
mkdir -p "$LAB"

Create an isolated Docker network for the database and WordPress containers:

sudo docker network create wpscan-lab

The network name lets containers resolve each other by hostname. Start MySQL on that network so WordPress can reach wp-db:

sudo docker run -d --name wp-db --network wpscan-lab -e MYSQL_ROOT_PASSWORD=labroot -e MYSQL_DATABASE=wordpress mysql:8.0

Wait until MySQL accepts connections before launching WordPress. A fixed sleep often fails on a cold image pull:

until sudo docker exec wp-db mysqladmin ping -h localhost -uroot -plabroot --silent; do sleep 2; done

The loop exits silently when MySQL answers. Start WordPress 6.4.3 on loopback only. The older core release is intentional so API lookups can return core findings later if you pass a token on a full scan:

sudo docker run -d --name wp-lab --network wpscan-lab --publish 127.0.0.1:42080:80 -e WORDPRESS_DB_HOST=wp-db:3306 -e WORDPRESS_DB_USER=root -e WORDPRESS_DB_PASSWORD=labroot -e WORDPRESS_DB_NAME=wordpress wordpress:6.4.3-php8.2-apache

Confirm the installer redirect responds:

curl -sI "$WP_URL/" | head -6

HTTP/1.1 302 Found
Date: Sat, 05 Sep 2026 07:49:13 GMT
Server: Apache/2.4.57 (Debian)
X-Powered-By: PHP/8.2.17
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0

A 302 toward the installer means Apache and PHP are up and WordPress has not finished setup yet. Download WP-CLI on the host next. Pulling the phar inside the container often fails on TLS to GitHub:

curl -sL -o /tmp/wp-cli.phar https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

Copy the phar into the container so WP-CLI runs against the site files:

sudo docker cp /tmp/wp-cli.phar wp-lab:/tmp/wp-cli.phar

Finish WordPress setup with a known admin password. You will reuse this account for user enumeration and the optional login check:

sudo docker exec -w /var/www/html wp-lab php /tmp/wp-cli.phar core install --url="$WP_URL" --title="WPScan Lab" --admin_user=admin --admin_password='LabPass123!' --admin_email=admin@lab.local --skip-email --allow-root

Success: WordPress installed successfully.

The site is now a normal WordPress install with user admin. Keep the lab running while you work through the scan sections below. When you finish, remove the containers and network with sudo docker rm -f wp-lab wp-db and sudo docker network rm wpscan-lab.

Prepare one deliberately vulnerable plugin for the lab

Later sections need a known outdated plugin so you can practice inventory, API CVE lines, and validation. Install wp-file-manager 6.0 (includes CVE-2020-25213). The wordpress.org zip for this old tag nests an inner archive named with letter O (wp-file-manager-6.O.zip), so unpack and re-zip before WP-CLI will accept it:

curl -sL -o /tmp/wp-file-manager.6.0.zip https://downloads.wordpress.org/plugin/wp-file-manager.6.0.zip

Clear any previous unpack directories, then create fresh folders:

rm -rf /tmp/wpfm-outer /tmp/wpfm-inner && mkdir -p /tmp/wpfm-outer /tmp/wpfm-inner

Unpack the outer wrapper, then the inner plugin zip:

unzip -qo /tmp/wp-file-manager.6.0.zip -d /tmp/wpfm-outer && unzip -qo /tmp/wpfm-outer/wp-file-manager/wp-file-manager-6.O.zip -d /tmp/wpfm-inner

Rebuild a clean zip whose top-level folder is wp-file-manager/:

(cd /tmp/wpfm-inner && zip -qr /tmp/wp-file-manager-clean.zip wp-file-manager)

Copy that clean zip into the container:

sudo docker cp /tmp/wp-file-manager-clean.zip wp-lab:/tmp/wp-file-manager-clean.zip

Install and activate it with WP-CLI:

sudo docker exec -w /var/www/html wp-lab php /tmp/wp-cli.phar plugin install /tmp/wp-file-manager-clean.zip --activate --allow-root

Give the plugin writable upload paths so it does not fatal-error author pages and XML-RPC:

sudo docker exec wp-lab bash -c 'mkdir -p /var/www/html/wp-content/uploads/wp-file-manager-pro/fm_backup && touch /var/www/html/wp-content/uploads/wp-file-manager-pro/fm_backup/index.php && chown -R www-data:www-data /var/www/html/wp-content/uploads'

For the passive-detection demo, append a small wp_head hook so the homepage links a plugin stylesheet. This is lab scaffolding to create a predictable public plugin reference. It does not mean every WordPress site or every WP File Manager install naturally exposes this exact asset:

sudo docker exec wp-lab bash -c 'cat >> /var/www/html/wp-content/themes/twentytwentyfour/functions.php <<EOF

add_action("wp_head", function () {
  echo "<link rel=\"stylesheet\" href=\"/wp-content/plugins/wp-file-manager/lib/themes/light/css/main.css\" />\n";
});
EOF'

Build an optional short password list for the later login check:

printf 'LabPass123!\nadmin\npassword\n' > "$LAB/pass.txt"

Run the first WordPress scan

A basic pass fingerprints WordPress without spending API quota on plugin enumeration. That is even more important on WPScan 4: the default scan focuses on WordPress version, the active theme, and security findings. Plugin discovery is explicit, so run -e p, -e ap, or -e vp only when you want it.

Save the full transcript instead of piping through head, which can interrupt the run:

wpscan --url "$WP_URL" --no-update 2>&1 | tee "$LAB/basic-scan.txt"

Sample output (trimmed):

Interesting Finding(s):

[+] Headers
 | Interesting Entries:
 |  - Server: Apache/2.4.57 (Debian)
 |  - X-Powered-By: PHP/8.2.17
 | Found By: Headers (Passive Detection)
 | Confidence: 100%

[+] XML-RPC seems to be enabled: http://127.0.0.1:42080/xmlrpc.php
 | Found By: Direct Access (Aggressive Detection)
 | Confidence: 100%

[+] WordPress readme found: http://127.0.0.1:42080/readme.html
 | Found By: Direct Access (Aggressive Detection)
 | Confidence: 100%

[+] The external WP-Cron seems to be enabled: http://127.0.0.1:42080/wp-cron.php
 | Found By: Direct Access (Aggressive Detection)
 | Confidence: 60%

[+] WordPress version 6.4.3 identified (Insecure, released on 2024-01-30).
 | Found By: Rss Generator (Passive Detection)

[+] WordPress theme in use: twentytwentyfour
 | Location: http://127.0.0.1:42080/wp-content/themes/twentytwentyfour/
 | Version: 1.0 (80% confidence)
 | Found By: Style (Passive Detection)

[!] No WPScan API Token given, as a result vulnerability data has not been output.
[!] You can get a free API token with 25 daily requests by registering at https://wpscan.com/register

[+] Finished: Sat Sep  5 04:12:24 2026
[+] Requests Done: 2

Read that block as orientation, not as a finished finding list:

• Headers confirm the web stack and give version clues for the report appendix
• Enabled XML-RPC matters later because many WordPress login checks abuse that endpoint
• readme.html, wp-cron.php, and the core version string prove WordPress and give you a baseline for later API lookups
• The active theme name (twentytwentyfour) appears without a full plugin walk
• The “No WPScan API Token” lines confirm fingerprinting worked while CVE titles stayed off

Notice there is no Plugin(s) Identified block. That is expected on WPScan 4 until you add -e. Paste the core version, theme name, and XML-RPC note into your notes before you chase CVEs. --no-update skips another metadata download because you already ran wpscan --update. If a production scan returns HTTP 403, retry with --random-user-agent only on authorized targets.

Get a WPScan API token for vulnerability data

Enumeration works without a token. Known-vulnerability titles do not. Configure the token before you expect [!] Title: lines, not after you are confused by an empty CVE section.

Register a free account at wpscan.com/register, confirm your email, then open your profile page and copy the API token. Treat it like any other secret:

• Keep it out of git and public screenshots
• Prefer an environment variable on the lab host
• Do not paste a live token into published tutorials

Export a placeholder on your machine and replace it with your real token locally:

export WPSCAN_API_TOKEN='YOUR_WPSCAN_API_TOKEN'

Pass --api-token whenever you want WPScan to correlate detected core, plugin, or theme versions with WPScan vulnerability records. Enumeration decides what components WPScan looks for; the API token decides whether matching vulnerability data can be shown. WPScan also accepts the token from a config file; the environment variable is enough for this lab.

At the time of testing, the free plan allows 25 API requests per day. Check WPScan pricing before you rely on that number, because plan limits can change. API usage generally scales with the number of core, plugin, and theme lookups WPScan performs, so broad -e ap / -e at scans can exhaust the free quota faster than a focused -e vp pass.

Without a token, WPScan still inventories components but prints:

[!] No WPScan API Token given, as a result vulnerability data has not been output.
[!] You can get a free API token with 25 daily requests by registering at https://wpscan.com/register

That message is the usual reason people think “WPScan found the plugin but not the CVEs.” The scanner did its job for fingerprinting. The vulnerability database simply never ran.

Enumerate plugins with vp, p, and ap

Plugin flags control what WPScan looks for. Detection mode (passive, aggressive, mixed) controls how it looks. On WPScan 4 you also choose --plugins-version-detection when you need a stable version string for API matching. Confusing those knobs is how people run a twenty-minute aggressive “all plugins” pass when they only needed a quiet inventory.

WPScan 4 also supports --wp-auth login:application-password for authorized Application Password-based plugin and theme inventory through the WordPress REST API. When credentials are available, that path can give a more authoritative installed list than black-box probing. Keep --wp-auth for authenticated assessments. This tutorial stays on external black-box enumeration.

Start with inventory, not with CVE lookup. Confirm the outdated lab plugin exists before you spend API quota. Passive detection finds the homepage reference; aggressive version detection reads readme.txt so you get a version instead of “could not be determined”:

wpscan --url "$WP_URL" -e ap --plugins-detection passive --plugins-version-detection aggressive --no-update

Sample output (trimmed):

[+] Enumerating All Plugins (via Passive Methods)

[+] wp-file-manager
 | Location: http://127.0.0.1:42080/wp-content/plugins/wp-file-manager/
 | Last Updated: 2026-04-21 12:53pm GMT (4 months ago, per WordPress.org)
 | Active Installs: 1,000,000 (per WordPress.org)
 | [!] The version is out of date, the latest version is 8.0.4
 |
 | Found By: Urls In Homepage (Passive Detection)
 |
 | Version: 6.0 (100% confidence)
 | Found By: Readme - Stable Tag (Aggressive Detection)
 |  - http://127.0.0.1:42080/wp-content/plugins/wp-file-manager/readme.txt
 | Confirmed By: Readme - ChangeLog Section (Aggressive Detection)

[i] 1 plugin(s) Identified.
[!] No WPScan API Token given, as a result vulnerability data has not been output.

Version 6.0 and “out of date” are inventory facts. Found By shows how WPScan first noticed the plugin. The missing [!] Title: blocks are the API gap from the previous section, not a scanner failure.

Now query vulnerable plugins with the token and the same detection choices that found the component:

wpscan --url "$WP_URL" -e vp --plugins-detection passive --plugins-version-detection aggressive --api-token "$WPSCAN_API_TOKEN" --no-update

Expect [!] Title: and Fixed in: lines under wp-file-manager when the token is valid and quota remains. The next section explains detection modes. Later you will read one vulnerability block field by field.

Passive vs aggressive vs mixed detection

Detection mode is independent of vp / p / ap. Aggressive is not automatically better. It sends more requests, takes longer, and may trip WAFs or rate limits on production sites.

In this lab, passive found wp-file-manager because the theme head linked the plugin CSS (lab scaffolding from earlier). Aggressive known-location checks can find the same plugin without that link by requesting the plugin directory directly.

On WPScan 4, --plugins-list overrides -e plugin options. For a single-plugin aggressive demo, pass the list alone instead of combining it with -e p:

wpscan --url "$WP_URL" --plugins-list wp-file-manager --plugins-detection aggressive --plugins-version-detection aggressive --no-update

Sample signal to look for:

[+] Enumerating Most Popular Plugins (via Aggressive Methods)

[+] wp-file-manager
 | Found By: Known Locations (Aggressive Detection)
 |  - http://127.0.0.1:42080/wp-content/plugins/wp-file-manager/, status: 200
 | Version: 6.0 (100% confidence)
 | Found By: Readme - Stable Tag (Aggressive Detection)

[i] 1 plugin(s) Identified.

Even though the banner says “Most Popular Plugins,” --plugins-list wp-file-manager restricts the actual candidate list to the slug you supplied. Known Locations (Aggressive Detection) with HTTP 200 means WPScan probed the expected path and the server answered. Use passive when HTML already leaks plugin paths. Reserve mixed or aggressive for blind targets, and expect longer runtimes and more log noise. On client work, match the mode to the rules of engagement: quiet first, louder only when authorized.

Enumerate themes and WordPress version

The basic scan already reported core 6.4.3 and theme twentytwentyfour. You do not always need a second pass for those two values. Dedicated theme enumeration helps when the active theme is unclear, when child themes matter, or when you want theme-specific API lookups with -e vt.

Theme flags mirror plugins:

• -e vt for vulnerable themes (needs API token for titles)
• -e t for popular themes
• -e at for all themes

Pair them with --themes-detection and, when needed, --themes-version-detection, the same way you chose plugin detection. --themes-list overrides -e theme options the same way --plugins-list does for plugins.

Version confidence comes from the Found By and Confirmed By lines in the transcript:

• Passive sources (RSS generator, meta generator, homepage URLs) are quieter and often good enough for a first note
• Aggressive sources (readme stable tag, direct CSS or readme access) often raise confidence to 100%

Record both the version string and the evidence method. “WordPress 6.4.3” without “found by RSS generator” is harder to defend if the client asks how you knew. When core says Insecure in the banner, treat that as a reminder to check API records and patch status, not as a finished exploit claim.

Enumerate WordPress users

User enumeration returns account identifiers such as admin. It does not reveal passwords. Stop after the username list unless password testing is in scope and authorized.

WPScan combines several techniques: RSS or author metadata, author ID patterns (?author=1), and login error messages that differ for valid vs invalid users. Hardened sites may block some of those paths and return nothing useful.

wpscan --url "$WP_URL" -e u --no-update 2>&1 | tee "$LAB/users.txt"

Sample output (trimmed):

[+] Enumerating Users (via Passive and Aggressive Methods)

[+] admin
 | Found By: Author Posts - Display Name (Passive Detection)

[i] 1 user(s) Identified.

admin is a login candidate for later testing, not proof the account uses a weak password. If exposing usernames is unnecessary, reduce author or user enumeration where practical, but do not rely on hidden usernames for account security. Strong authentication and rate limiting matter more. Password guessing belongs in a separate authorized step (see the optional section below or web form brute force for HTTP forms outside WPScan).

Read WPScan vulnerability results

With an API token, -e vp printed nine records under wp-file-manager 6.0 on this lab. You do not need to chase all nine in one sitting. Focus on one concrete finding for report practice: File Manager 6.0–6.9 – Unauthenticated Arbitrary File Upload leading to RCE (CVE-2020-25213). That record is well documented and maps cleanly from detected version to fixed version.

Re-run vulnerable-plugin enumeration if you need a fresh transcript for notes:

wpscan --url "$WP_URL" -e vp --plugins-detection passive --plugins-version-detection aggressive --api-token "$WPSCAN_API_TOKEN" --no-update

Sample output (trimmed to that finding):

[+] wp-file-manager
 | Location: http://127.0.0.1:42080/wp-content/plugins/wp-file-manager/
 | [!] The version is out of date, the latest version is 8.0.4
 |
 | Found By: Urls In Homepage (Passive Detection)
 |
 | [!] 9 vulnerabilities identified:
 |
 | [!] Title: File Manager 6.0-6.9 - Unauthenticated Arbitrary File Upload leading to RCE
 |     UUID: e528ae38-72f0-49ff-9878-922eff59ace9
 |     Fixed in: 6.9
 |     References:
 |      - https://wpscan.com/vulnerability/e528ae38-72f0-49ff-9878-922eff59ace9
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25213
 |
 | Version: 6.0 (100% confidence)
 | Found By: Readme - Stable Tag (Aggressive Detection)

[+] WPScan DB API OK
 | Plan: free
 | Requests Done (during the scan): 1
 | Requests Remaining: 19

Read the block field by field before you escalate:

• Plugin slug and detected version (wp-file-manager / 6.0) are the inventory facts
• Vulnerability title describes the issue class (here, unauthenticated upload leading to RCE)
• UUID identifies the WPScan advisory record
• Fixed in: 6.9 means WPScan identifies 6.9 as the patched boundary for the affected branch shown in this advisory record
• References point to the WPScan advisory and CVE entry you should open before testing
• WPScan DB API OK plus Requests Remaining confirm the token worked and how much free quota is left

On this lab, installed version 6.0 is below 6.9, so the record applies by version. That still does not prove RCE until you validate the vulnerable functionality safely under authorization. Out-of-date alone is not the same as “exploited.”

WPScan says a plugin is vulnerable: now what?

A red [!] Title: line is the start of analysis, not the end of the finding. Use this workflow before you open an exploit module or write a critical severity:

1. Confirm the detected version against the plugin readme or admin UI so you are not chasing a false fingerprint
2. Read the advisory and prerequisites (auth required? multisite only? specific endpoint still present?)
3. Check whether the vulnerable feature is enabled or reachable on the target
4. Validate safely in the lab with minimal proof. Avoid destructive cleanup games on shared hosts
5. Prioritize with business impact using vulnerability prioritization

For CVE-2020-25213, the advisory describes unauthenticated file upload in affected File Manager versions. Your notes should show version evidence, the fixed-in release, and whether you validated the upload path. This page stops at WPScan evidence and prioritization. Full exploitation and reverse-shell follow-ups belong on dedicated exploit guides, not here.

Optional: short WordPress login check

Only after user enumeration, and only on systems you may test, WPScan can try a small password list against a named account. This is noisy, shows up in logs, and is easy to overuse. Keep the wordlist tiny in labs.

This lab reuses admin and "$LAB/pass.txt". Prefer custom lists from a wordlist generator when you know password patterns on a real engagement.

wpscan --url "$WP_URL" -U admin -P "$LAB/pass.txt" --no-update 2>&1 | tee "$LAB/brute.txt"

Sample output (trimmed):

[+] Performing password attack on Xmlrpc against 1 user/s

[SUCCESS] - admin / LabPass123!

[!] Valid Combinations Found:
 | Username: admin, Password: LabPass123!

[SUCCESS] means the guessed password worked through the XML-RPC login path. That matches the weak lab password you set during install. If XML-RPC is not required, reducing or restricting that attack surface can limit one password-testing path; the primary defenses remain strong credentials, MFA where applicable, and rate limiting. Broader form brute force against wp-login.php or other apps stays outside this WPScan-focused page.

Troubleshooting

Use this table when a scan stops early or the output looks empty. Most WPScan “failures” are missing updates, missing tokens, wrong URLs, or detection mode mismatches.

WPScan vs general web scanners

WPScan is specialized. Other scanners cover different layers of the same engagement. Pick the tool for the question you are asking.

Use WPScan when the target is WordPress and you need component inventory plus known-vuln correlation. Pair it with Nikto or Nuclei for broader surface area, then validate interesting findings manually in Burp. Running every tool at once without a plan usually creates duplicate noise.

Summary

You verified WPScan 4.1.0 on Kali, refreshed local metadata, and scanned a loopback Docker WordPress lab on port 42080. The default first pass reported core 6.4.3, the Twenty Twenty-Four theme, and enabled XML-RPC without automatically walking plugins. Explicit -e ap inventory found wp-file-manager 6.0, and an API token added [!] Title: lines including CVE-2020-25213 with a fixed-in version of 6.9.

The main pitfall is treating inventory as vulnerability proof, or treating API titles as guaranteed exploits. Confirm versions, read advisories, and prioritize before you escalate. On WPScan 4, remember that plugin enumeration is explicit, --plugins-list overrides -e, and --plugins-version-detection matters when you need a version for CVE matching. User enumeration only exposes account names; password checks stay optional, authorized, and secondary.

Next steps on an authorized engagement: validate the highest-priority plugin findings, patch or remove outdated components on systems you administer, and continue web testing in Burp when the scope goes beyond WordPress fingerprinting.

References

• WPScan
• WPScan Vulnerability Database API
• WPScan pricing and API plans
• WPScan user documentation (GitHub wiki)
• WPScan on Kali Tools
• WPScan GitHub repository
• wp-file-manager on WPScan