WPScan Tutorial Kali Linux 2026 — WordPress Vulnerability Scanner

🖥️ KALI LINUX COURSE
FREE

Part of the 180-Day Kali Linux Mastery Course

Day 17 of 180 · 9.4% complete

⚠️ Authorised Targets Only: WPScan sends hundreds of HTTP requests to the target WordPress site. Only use it against sites you own or have explicit written authorisation to test. Running WPScan against any site without authorisation is illegal under computer fraud laws worldwide.

WPScan Tutorial Kali Linux 2026 :— WordPress powers over 40% of the web. Every WordPress site is a potential target with a standardised attack surface: predictable plugin paths, a user enumeration endpoint that has existed for a decade, an XML-RPC interface that enables brute force, and a plugin ecosystem where outdated versions carry known CVEs with public exploit code. WPScan automates the discovery of every one of these attack surfaces in a single command. Day 17 teaches you how to use it properly — from API token setup through aggressive plugin enumeration and user discovery.

🎯 What You’ll Master in Day 17

Install, update, and configure WPScan with a free API token for CVE data

Run passive and aggressive scans to identify plugins, themes, and WordPress versions

Enumerate valid WordPress usernames using multiple techniques

Interpret WPScan output and prioritise findings by severity

Chain WPScan findings into credential testing and exploitation workflows

⏱️ 45 min read · 3 hands-on exercises

📋 WPScan Tutorial Kali Linux 2026

Setup — Installation, Update, and API Token
Basic WordPress Scan — Version, Plugins, Themes
User Enumeration — Finding Valid Usernames
Aggressive Mode — Complete Plugin and Theme Discovery
Interpreting Results and Prioritising Findings

In Day 16 you used DirBuster to discover hidden directories on web servers. Day 17 takes web enumeration to the next level — WPScan is to WordPress what DirBuster is to generic web servers, but with built-in CVE intelligence. Together they form the complete web application reconnaissance toolkit in the 180-Day Kali Linux Mastery Course.

Setup — Installation, Update, and API Token

WPSCAN SETUP AND API TOKEN CONFIGURATION

# WPScan is pre-installed in Kali Linux

wpscan –version

WPScan v3.8.x

# Update WPScan and its vulnerability database

wpscan –update

[i] Updating the Database …

[i] Update completed

# If not installed:

sudo apt install ruby-full build-essential -y

sudo gem install wpscan

# Get free API token at: wpscan.com (25 free requests/day)

# Add token to config file (permanent)

echo “cli_options:” > ~/.wpscan/scan.yml

echo ” api_token: YOUR_API_TOKEN_HERE” >> ~/.wpscan/scan.yml

# Or pass per-scan:

wpscan –url https://target.com –api-token YOUR_TOKEN

# Verify token works

wpscan –url https://target.com –api-token YOUR_TOKEN 2>&1 | grep “API”

[+] WPScan API Token found, vulnerability data will be displayed

🧠 EXERCISE 1 — THINK LIKE A HACKER (8 MIN · NO TOOLS)

Why Does WordPress’s Plugin Architecture Make It a High-Value Target?

⏱️ Time: 8 minutes · No tools required

WordPress has over 59,000 plugins in the official repository.
Think through the security implications:

1. PLUGIN LIFECYCLE PROBLEM:
A site installs a plugin in 2022, uses it for 6 months,
then deactivates it but never deletes it.
The plugin receives a critical security patch in 2024.
→ What is the security implication? Is the site vulnerable?
→ Would WPScan’s aggressive mode find this plugin?

2. THIRD-PARTY CODE TRUST:
A developer submits a plugin to the WordPress repository.
It has a backdoor. It gets 10,000 installs before discovery.
→ What trust model does WordPress use for plugins?
→ How does this compare to enterprise software procurement?

3. ENUMERATION STANDARDISATION:
WordPress installs all plugins under /wp-content/plugins/[name]/
with predictable file paths (readme.txt contains version number).
→ Why does this standardisation help attackers?
→ How would you defend against plugin version fingerprinting?

4. THE LONG TAIL:
Most WordPress vulnerabilities are in plugins with under
1,000 active installs — niche plugins that maintain small
sites without dedicated security teams.
→ Why does this create a disproportionate attack surface?

Write a 3-sentence assessment of why WordPress’s architecture
creates a persistent security challenge despite its popularity.

✅ What you just learned: The WordPress plugin architecture creates a perfect storm of security challenges: standardised file paths enable automated version fingerprinting, deactivated-but-not-deleted plugins remain vulnerable, the trust model for plugin code is weaker than enterprise software procurement, and the long tail of niche plugins means most vulnerabilities affect sites maintained without dedicated security resources. WPScan’s effectiveness is a direct consequence of this architecture — standardisation that makes WordPress easy to build on also makes it systematically assessable. This analysis belongs in the contextual framing section of any WordPress penetration test report.

📸 Share your 3-sentence WordPress security architecture assessment in #day-17-wpscan on Discord.

Basic WordPress Scan — Version, Plugins, Themes

BASIC WPSCAN — FULL OPTIONS

# Standard full scan with CVE data

wpscan –url https://target.com –api-token YOUR_TOKEN

# Key output sections:

[+] WordPress version 6.2.1 identified (Outdated, released 2023-05-18)

[i] The main theme could not be detected

[+] WordPress theme in use: twentytwentythree

[+] Plugin: woocommerce 7.4.0

| [!] Title: WooCommerce < 7.4.1 - Reflected XSS

| Fixed in: 7.4.1

| CVE: CVE-2023-XXXX

[+] Plugin: contact-form-7 5.7.1

| [!] 1 vulnerability identified:

| SQLi via file upload bypass (CVE-2020-12800)

# Save output to file

wpscan –url https://target.com –api-token YOUR_TOKEN -o scan_results.txt

# JSON output for scripting

wpscan –url https://target.com –api-token YOUR_TOKEN –format json -o results.json

securityelites.com

WPScan Output — Vulnerability Summary Panel
_______________________________________________________________
        __          _______   _____
        \ \        / /  __ \ / ____|
         \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
          \ \/  \/ / |  ___/ \___ \ / __|/ _` | ‘_ \
[+] URL: https://target.com/ [203.0.113.42]
[+] Started: Fri Apr 11 09:15:22 2026
[+] WordPress version 6.2.1 identified (Outdated)
[+] WordPress theme in use: Astra v3.9.2
[+] Plugin: elementor 3.14.0
| [!] 2 vulnerabilities identified
| Title: Authenticated XSS via Widget Title
| CVE: CVE-2023-XXXXX | CVSS: 6.4 Medium
[+] Plugin: woocommerce 7.4.0
| [!] 1 Critical vulnerability
[i] User(s) Identified:
[+] admin | Found By: Author Posts — Url (Passive Detection)

📸 WPScan output showing WordPress version, plugin vulnerabilities with CVE references, and discovered admin username — in a single automated scan. This output directly feeds into the vulnerability assessment section of a penetration test report.

User Enumeration — Finding Valid Usernames

USER ENUMERATION COMMANDS

# Enumerate users (passive + active methods)

wpscan –url https://target.com –enumerate u

# Enumerate users 1-50 (ID range scan)

wpscan –url https://target.com –enumerate u1-50

[i] User(s) Identified:

[+] admin

| Found By: Author Posts – Url (Passive Detection)

| Confirmed By:

| Rss Generator (Passive Detection)

| WP REST API v2 (Aggressive Detection)

[+] john.smith

| Found By: WP REST API v2 (Aggressive Detection)

# Manually verify via author archive

curl -s “https://target.com/?author=1” | grep -i “location”

Location: https://target.com/author/admin/

# Disable user enumeration on WordPress (defensive)

# Add to .htaccess or use a security plugin:

RewriteCond %{QUERY_STRING} author=\d

RewriteRule ^ /? [L,R=301]

⚡ EXERCISE 2 — KALI TERMINAL (20 MIN)

Run WPScan Against a Practice WordPress Target

⏱️ Time: 20 minutes · Kali terminal · authorised practice target only

WPSCAN PRACTICE — COMPLETE SCAN SEQUENCE

# Option 1: Scan your own local WordPress (best for learning)

# Install XAMPP + WordPress locally first

wpscan –url http://localhost/wordpress/ –api-token YOUR_TOKEN

# Option 2: Use DVWA/Metasploitable which may have WordPress component

# Option 3: WPScan has a test site (check wpscan.com for demo targets)

# Full scan sequence:

# Step 1: Quick basic scan

wpscan –url TARGET –api-token YOUR_TOKEN 2>&1 | tee step1_basic.txt

# Step 2: User enumeration

wpscan –url TARGET –enumerate u –api-token YOUR_TOKEN 2>&1 | tee step2_users.txt

# Step 3: Aggressive plugin detection

wpscan –url TARGET –enumerate ap –plugins-detection aggressive \

–api-token YOUR_TOKEN 2>&1 | tee step3_plugins.txt

# Step 4: All enumeration combined

wpscan –url TARGET –enumerate u,ap,at,cb,dbe \

–plugins-detection aggressive –api-token YOUR_TOKEN \

-o full_scan.json –format json

# Enumeration flags: u=users ap=all-plugins at=all-themes

# cb=config-backups dbe=db-exports

# Step 5: Count findings

grep -c “vulnerability” step3_plugins.txt

grep “CVE” step3_plugins.txt

✅ What you just learned: The four-step WPScan sequence mirrors a professional WordPress assessment workflow: basic scan for version and obvious findings, user enumeration for credential attack targets, aggressive plugin scan for comprehensive CVE coverage, and full combined scan for report evidence. The JSON output flag is particularly useful for importing results into vulnerability management platforms or custom reporting scripts. The config-backups (cb) and db-exports (dbe) enumeration flags are the most often-overlooked — they find backup files like wp-config.php.bak that contain database credentials and are among the highest-severity WordPress findings possible.

📸 Screenshot your WPScan results showing identified plugins/versions and share in #day-17-wpscan on Discord.

Aggressive Mode — Complete Plugin and Theme Discovery

The difference between passive and aggressive detection is the difference between finding what is advertised and finding everything that is installed. Passive detection reads plugin references from page source code. Aggressive detection systematically requests known plugin file paths — WPScan maintains a database of over 50,000 plugin directory names and checks each one for the presence of readme.txt (which contains the version number). This discovers inactive, hidden, and legacy plugins that would never appear in passive scanning.

⚡ EXERCISE 3 — KALI TERMINAL (12 MIN)

Chain WPScan Findings to a Credential Attack with Hydra

⏱️ Time: 12 minutes · Kali terminal · own local WordPress only

WPSCAN → HYDRA CREDENTIAL ATTACK CHAIN

# Step 1: Enumerate users with WPScan

[+] admin

[+] editor_user

# Step 2: Save usernames to file

echo “admin” > users.txt && echo “editor_user” >> users.txt

# Step 3: WPScan built-in password brute force

wpscan –url http://localhost/wordpress/ \

–usernames users.txt \

–passwords /usr/share/wordlists/rockyou.txt \

–max-threads 5

# Step 4: Alternative — Hydra for HTTP POST brute force

hydra -L users.txt -P /usr/share/wordlists/rockyou.txt \

localhost http-post-form \

“/wordpress/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In:Invalid username”

# SUCCESS indicator: absence of “Invalid username” or “incorrect password” in response

# Also check XML-RPC if available:

wpscan –url http://localhost/wordpress/ –enumerate u –password-attack xmlrpc

✅ What you just learned: The WPScan-to-Hydra chain demonstrates the reconnaissance-to-exploitation workflow: WPScan enumerates usernames, Hydra uses those usernames with a wordlist to test credentials against the WordPress login form. WPScan’s built-in password attack feature is convenient but slower than Hydra; Hydra is preferred for production assessments where speed matters. The XML-RPC attack path is often more effective than the web form because XML-RPC enables bulk credential testing in a single request, bypassing some rate limiting implementations that only apply to the web login form.

📸 Screenshot the complete WPScan → credential attack chain on your local WordPress and share in #day-17-wpscan on Discord. Tag #wpscan2026

🧠 QUICK CHECK — Day 17

A WordPress site has the contact-form-7 plugin installed and deactivated. WPScan’s passive scan does not find it. WPScan’s aggressive scan finds it at version 4.9.2 which has a known SQLi vulnerability. Why is this finding significant even though the plugin is deactivated?

📋 Commands Used Today — Day 17 WPScan Reference

wpscan –updateUpdate WPScan and vulnerability database — run before every assessment

wpscan –url TARGET –api-token TOKENBasic scan — WordPress version, active plugins/themes + CVEs

–enumerate uUser enumeration — discovers valid WordPress usernames

–enumerate ap –plugins-detection aggressiveAll plugins including inactive — comprehensive coverage

–enumerate u,ap,at,cb,dbeFull enumeration — users, all plugins, all themes, config backups, DB exports

–format json -o results.jsonJSON output for scripting and vulnerability management import

–passwords wordlist.txtBuilt-in password attack — chain with –usernames flag

🏆 Mark Day 17 as Complete

WPScan is one of the most practically useful tools in your Kali arsenal because WordPress is everywhere. The combination of version fingerprinting, CVE mapping, user enumeration, and aggressive plugin discovery gives you a comprehensive WordPress attack surface in under 5 minutes. Day 18 covers Crunch — the password list generator that feeds the credential attacks Day 17 sets up.

❓ Frequently Asked Questions

What is WPScan and what does it find?

WordPress-specific scanner pre-installed in Kali. Finds: WordPress version, plugin and theme versions with CVEs (requires free API token), valid usernames, config backups, database exports, XML-RPC availability. Queries WPVulnDB for vulnerability data.

Does WPScan need an API token?

Runs without one but no CVE data. Free tier at wpscan.com = 25 API requests/day — sufficient for most learning and low-volume professional use. Without token: version numbers identified but no vulnerability mapping.

Is WPScan legal to use?

Only against sites you own or have explicit written authorisation to test. Check bug bounty programme scope carefully — some prohibit automated scanning. Unauthorised use is illegal under computer fraud laws.

What is passive vs aggressive detection?

Passive: finds plugins referenced in page source only. Aggressive: requests thousands of known plugin paths — finds inactive/hidden plugins. Aggressive is noisier (triggers IDS/WAF) but provides complete coverage for authorised assessments.

How does WPScan enumerate users?

Author archive URLs (?author=1 → redirects to /author/USERNAME/), WordPress REST API /wp-json/wp/v2/users/, and XML-RPC. The –enumerate u flag enables all methods. Discovered usernames feed into Hydra/WPScan credential attacks.

What comes after Day 17?

Day 18: Crunch — password list generation. Building wordlists targeted to the discovered usernames and organisation’s naming conventions, completing the recon-to-credential-attack workflow.

← Previous

Day 16: DirBuster Tutorial 2026

Day 18: Crunch Password Generator 2026

📚 Further Reading

DirBuster Tutorial Kali Linux 2026 — Day 16 covers generic web directory discovery — the broader web enumeration technique that WPScan specialises for WordPress targets.
Kali Linux Tools Hub — Complete Kali Linux tools reference — WPScan in context with the full web application assessment toolkit including Nikto, Gobuster, Burp Suite, and SQLmap.
180-Day Kali Linux Mastery Course — The complete course hub — Day 17 WPScan is part of the web application reconnaissance phase covering Days 14–22.
WPScan GitHub Repository — Official WPScan source code and documentation — complete flag reference, custom detection rules, API documentation, and contribution guide for the WPVulnDB vulnerability database.
WPScan Wordlists — Official WPScan wordlists for plugin and theme detection — understanding what the aggressive scan is checking helps interpret why it finds inactive plugins the passive mode misses.

Mr Elite

Owner, SecurityElites.com

The WPScan finding that consistently impresses clients most is the config backup discovery — not the CVEs, not the user enumeration, but the moment I show them a file like wp-config.php.bak accessible at the site root, containing their production database credentials in plaintext. It happens because a developer edited the config file, their editor automatically created a backup with the .bak extension, and nobody thought to delete it or add it to .htaccess restrictions. WPScan’s –enumerate cb flag finds it in seconds. I have found this on sites that passed a major security audit six months prior. The audit checked the application. Nobody ran WPScan. Those are different things. Run WPScan on every WordPress site you assess.

WPScan Tutorial Kali Linux 2026 — Scan WordPress Sites, Find Vulnerabilities & Enumerate Users | Tools Day17