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

This article is a detailed tutorial on WPScan, a WordPress-specific security scanner included in Kali Linux, teaching users how to enumerate WordPress installations, identify vulnerable plugins and themes, discover valid usernames, and chain findings into credential attacks. The article argues that WordPress's standardised architecture—predictable file paths, a decade-old user enumeration endpoint, and a large plugin ecosystem with outdated versions carrying public CVEs—makes it systematically vulnerable to automated scanning. WPScan matters because WordPress powers over 40% of the web, making WordPress security assessments a critical skill for penetration testers.

• WordPress architecture creates systematic attack surfaceThe article explains that WordPress stores all plugins under /wp-content/plugins/[name]/ with predictable file paths, and plugin readme.txt files contain version numbers, enabling automated fingerprinting. Deactivated-but-not-deleted plugins remain accessible and vulnerable on disk even after being disabled. The trust model for the 59,000+ plugins in the official repository is weaker than enterprise software procurement, and niche plugins with small user bases often lack dedicated security teams, creating a disproportionate attack surface.
• Passive versus aggressive detection differencesPassive detection reads plugin references from page source code only, while aggressive detection systematically requests known plugin file paths from WPScan's database of over 50,000 plugin directory names to check for readme.txt files. Aggressive mode discovers inactive, hidden, and legacy plugins that never appear in passive scanning. This distinction is critical because deactivated plugins remain vulnerable but invisible to passive scans, yet WPScan's aggressive mode will find them.
• Setup requires free API token for CVE mappingWPScan is pre-installed in Kali Linux but requires a free API token from wpscan.com for vulnerability data; the free tier provides 25 API requests per day. The token can be permanently configured in ~/.wpscan/scan.yml or passed per-scan with the --api-token flag. Without a token, WPScan identifies version numbers but cannot map them to CVEs or vulnerability details.
• Basic scan reveals version and active plugin vulnerabilitiesA standard WPScan command with API token outputs WordPress version (marked as outdated or current), active themes and plugins with version numbers, and any known CVEs with references and CVSS scores. For example, the article shows WooCommerce 7.4.0 identified with a reflected XSS vulnerability fixed in 7.4.1, and Contact Form 7 5.7.1 with a SQLi vulnerability. Output can be saved as text or JSON for scripting and vulnerability management platform import.
• User enumeration feeds credential attack workflowsWPScan discovers valid WordPress usernames through multiple methods: author archive URLs (?author=1 redirects to /author/USERNAME/), WordPress REST API at /wp-json/wp/v2/users/, and XML-RPC. The --enumerate u flag enables all methods, and discovered usernames are then used with Hydra or WPScan's built-in password attack feature. XML-RPC is noted as often more effective than web form attacks because it enables bulk credential testing in single requests, potentially bypassing rate limiting applied only to the login form.
• Aggressive enumeration flags discover critical backup filesThe --enumerate ap,at,cb,dbe flags enable all-plugins, all-themes, config-backups, and database-exports enumeration. The config-backups flag (cb) is highlighted as the most overlooked but highest-severity finding—it discovers files like wp-config.php.bak accessible at the site root containing production database credentials in plaintext. The article notes this finding occurs when developers edit config files, editors auto-create .bak backups, and nobody deletes them or restricts access via .htaccess.
• Deactivated plugin vulnerabilities remain exploitableEven when a plugin is deactivated, its files remain on disk under /wp-content/plugins/ and remain accessible at standard HTTP paths. If a vulnerability is in the plugin's file processing code triggerable via direct HTTP requests (rather than through WordPress admin), deactivation does not prevent exploitation. Deactivated plugins receive no admin attention for updates, so vulnerabilities often persist longer than in active plugins, warranting High severity ratings and recommendations to delete rather than merely deactivate unused plugins.
• Complete scan workflow mirrors professional assessment processThe article demonstrates a four-step WPScan sequence: basic scan for version and obvious findings, user enumeration for credential attack targets, aggressive plugin scan for comprehensive CVE coverage, and full combined scan with JSON output for report evidence. This workflow mirrors real WordPress penetration test methodology, with findings documented and imported into vulnerability management systems for formal reporting.

Bottom line: WPScan automates discovery of WordPress's entire standardised attack surface—versions, plugins, themes, users, and backup files with CVEs—in under 5 minutes, making it essential for any WordPress assessment; however, it must only be used against sites you own or have explicit written authorisation to test, as unauthorised use violates computer fraud laws worldwide. The tool's most valuable finding is often overlooked config backup files (wp-config.php.bak) containing production credentials, whic