You've updated your plugins, configured HTTPS, and set up a firewall. Your site looks secure. But how do you know that one of the installed plugins doesn't have a vulnerability that's being exploited right now?

Manual cross-checking with vulnerability databases takes hours. WPScan does it in half a minute: an open-source WordPress security scanner with a command-line interface that, according to its own database statistics, tracks over 73,000 vulnerabilities in core, plugins, and themes. Below: installation, API token, basic and advanced scanning, password brute-forcing.

💡 Quick overview:

• Install WPScan via Ruby gem, Docker, or Homebrew and update the metadata database with wpscan --update

• Register a free API token at wpscan.com: 25 requests per day, without a token the scanner won't show vulnerability data

• Run a basic scan: wpscan --url https://your-site.com --api-token YOUR_TOKEN

• Check vulnerable plugins and themes with -e vp and -e vt flags, enumerate users with -e u

• For password brute-forcing, prepare a wordlist file and pass it with the --passwords flag

What is WPScan

WPScan, a free-for-non-commercial-use WordPress security scanner, is written in Ruby. The first release came out in June 2011, and since then the tool has become the de facto standard for pentesting WordPress sites.

The scanner cross-checks the installed WordPress version, active plugins, and themes against the WordPress Vulnerability Database at wpscan.com, maintained by a team of security specialists. According to database statistics, it documents over 73,000 vulnerabilities in core, plugins, and themes. Each entry is manually verified by a dedicated team of WordPress experts. Since 2023, WPScan is a CVE Numbering Authority and directly assigns CVE numbers to vulnerabilities in the WordPress ecosystem.

Beyond vulnerabilities, WPScan can enumerate user logins via the REST API and author feeds, brute-force passwords from a dictionary, find exposed wp-config.php backups, database dumps, and open error logs.

An important licensing nuance: free CLI scanner use is allowed only for non-commercial purposes. Agencies scanning client sites need a paid subscription. Terms are described on the official WPScan site.

Installation and updates

WPScan is available three ways. Choose the one that fits your workflow.

Ruby gem, universal option for Linux, macOS, and Windows with Ruby installed:

1
gem install wpscan

Docker, isolated environment without dependencies:

1
docker pull wpscanteam/wpscan

Example Docker run:

1
docker run -it --rm wpscanteam/wpscan --url https://example.com -e u

Homebrew, for macOS:

1
brew install wpscanteam/tap/wpscan

After installation, first update the local metadata database. It contains information about the latest plugin and theme versions, without it the scanner won't determine if the installed version is outdated. Vulnerability information is requested separately via API in real time.

1
wpscan --update

The update takes a few seconds. The output will show the WPScan version and confirmation that the database is current. Repeat wpscan --update before each audit: developers release metadata updates several times a week.

API token: the key to vulnerability data

The most common beginner mistake: running wpscan --url site.com without a token and wondering why the scanner is silent about vulnerabilities. Without a token, WPScan operates in "metadata only" mode. It will report that a plugin is outdated, but won't say which CVEs are associated with it.

Register at wpscan.com, it's free and takes a minute. The free plan gives 25 API requests per day. One scan consumes 1 request for the WordPress version, 1 request for each installed plugin, and 1 request for each theme. A typical WordPress site has more than a dozen plugins installed, so the free limit is enough for one full scan per day.

The token is passed with the --api-token flag at each run:

1
wpscan --url https://example.com --api-token YOUR_TOKEN

To avoid entering the token in every command, save it to the configuration file ~/.wpscan/scan.yml:

1
api_token: YOUR_TOKEN

After that, WPScan will pick up the token automatically.

Basic site scanning

Minimal audit command:

1
wpscan --url https://example.com --api-token YOUR_TOKEN

The scanner will determine the WordPress version, active theme, detect exposed version numbers, and check basic configuration issues: wp-cron and readme.html accessibility, the uploads directory, user registration capability.

Output is structured with color markers: green for informational messages, yellow for warnings, red for found vulnerabilities. Each vulnerability is accompanied by a link to the WPScan database card with a description of the attack vector, affected versions, and remediation recommendations.

Basic scanning usually takes under a minute. Exact time depends on site size and hosting speed.

Finding vulnerable plugins

Plugins, the main attack vector on WordPress. According to WPScan statistics, over 90% of known vulnerabilities are in plugins. The check command:

1
wpscan --url https://example.com -e vp --api-token YOUR_TOKEN

The -e vp flag (enumerate vulnerable plugins) lists only plugins with known vulnerabilities. This is the fastest and most practical mode: it cross-checks installed plugins against the database and reports only those with documented issues.

By default, WPScan uses passive detection mode, analyzing page HTML without extra requests. To get maximum coverage at the cost of additional server load, switch to mixed mode:

1
wpscan --url https://example.com -e vp --plugins-detection mixed --api-token YOUR_TOKEN

The mixed mode first applies passive analysis, then aggressively checks known plugin paths to detect hidden and inactive installations.

If the scanner found a vulnerable plugin, update it to the latest version. The developer has almost certainly released a patch. If there's no update and the plugin is abandoned, remove it and find an alternative. Leaving a plugin with a known vulnerability on a production site is unacceptable.

Finding vulnerable themes

Themes are checked similarly to plugins:

1
wpscan --url https://example.com -e vt --api-token YOUR_TOKEN

The -e vt flag (vulnerable themes) checks the active theme and all installed themes for known vulnerabilities. Themes are attacked less frequently than plugins, but vulnerabilities occur, especially in themes with built-in page builders and sliders.

The default theme detection mode is aggressive, since passive analysis often misses inactive themes. If the server is weak and load is critical, limit to passive mode:

1
wpscan --url https://example.com -e vt --themes-detection passive --api-token YOUR_TOKEN

When a vulnerable theme is found, act on the same principle: update or remove. Child themes inherit parent theme vulnerabilities, check both.

User enumeration

An attacker who knows WordPress user logins only needs to guess passwords. WPScan shows which logins are visible from outside:

1
wpscan --url https://example.com -e u

The scanner iterates through user IDs and extracts logins from the REST API, author feeds (/author/name/), and other public endpoints. The result looks like this:

1
[i] User(s) Identified:
2
[+] admin
3
[+] editor
4
[+] serg

Ideally, you should see no logins. If WPScan found users, take measures:

• Set a display name different from the login in profile settings.
• Disable REST API for unauthorized visitors via a plugin or .htaccess.
• DNS-level firewall, like Sucuri or Cloudflare, will block the scanner before it arrives: you'll see a timeout error instead of a user list.

Current WordPress versions limit enumeration via REST API, but themes and plugins can open workarounds. Relying on core alone is insufficient.

Password brute-forcing

WPScan supports dictionary password attacks. The scanner attempts to authenticate as each found user with each password from a list file. The operation is resource-intensive, but the result is worth it: you'll find out if any administrators are using qwerty123.

Prepare a text file with passwords, one per line, and run:

1
wpscan --url https://example.com -e u --passwords /path/to/passwords.txt

Ready-made wordlists are available in Kali Linux (/usr/share/wordlists/) and open sources like the SecLists repository on GitHub. For a basic check, a file of 500-1000 most common passwords is sufficient.

The --threads N parameter controls the number of simultaneous attempts. The default value is 5. Increasing to 20-30 will speed up brute-forcing but will create noticeable server load and may trigger hosting protection.

Before running brute-force, back up the site and notify the hosting provider: some block IPs for multiple failed login attempts.

Additional capabilities

WPScan can do more than basic plugin and user audits. Here are some useful scenarios.

Finding all plugins, not just vulnerable ones:

1
wpscan --url https://example.com -e ap --api-token YOUR_TOKEN

The -e ap flag (all plugins) enumerates all plugins from the WPScan database. The operation takes considerable time. Use for full audits, not regular checks.

Detecting backups and dumps:

1
wpscan --url https://example.com -e cb,dbe

Flags cb (config backups) and dbe (database exports) search for publicly accessible wp-config.php backups and SQL dumps accidentally left by backup plugins. Such a file in open access is critically dangerous: an attacker gains database credentials.

Stealth scanning:

1
wpscan --url https://example.com --stealthy --api-token YOUR_TOKEN

The --stealthy flag adds random delays between requests, masking scanner activity as normal visitor behavior. Useful if the server aggressively bans suspicious activity.

Media file enumeration:

1
wpscan --url https://example.com -e m1-100

Checks media file IDs in the specified range. Helps discover confidential documents accessible by direct link and backups uploaded outside the media library.

Full WPScan video tutorial, from installation to advanced scenarios:

⁉️🤔 Frequently asked questions

Is WPScan needed if Jetpack Protect or Wordfence is already installed?

Yes, it's needed. Security plugins work from inside WordPress and block attacks in real time. WPScan looks at the site from outside, just like an attacker. It finds issues the plugin doesn't see: exposed backups, user enumeration through non-standard vectors, vulnerabilities in inactive but not removed plugins. Both approaches together provide real defense in depth.

Is WPScan safe for my site? Won't it crash the server?

The scanner sends standard HTTP requests, the same as a regular visitor. In passive mode, it only analyzes HTML without additional load. Aggressive mode with full plugin enumeration (-e ap) generates hundreds of requests and can slow down weak hosting. For regular checks, use -e vp,vt,u, that's a few dozen requests, safe for any server.

Can scanning be automated?

Yes. For developers, a cron job running a Docker container once a week and sending a report by email works well. For everyone else, the WPScan.com service automatically scans sites on schedule and sends notifications about new vulnerabilities. Optimal frequency: full scan once a week, high-priority component checks daily. For manual audits, the free CLI is sufficient, for continuous monitoring consider an automated solution.

What to do if WPScan found a vulnerability and there's no update?

The plugin is abandoned by the developer. Algorithm: (1) check if the vulnerability is actively exploited, the WPScan database card contains this information; (2) if there are no attacks and the plugin is critical for business, temporarily restrict access to it via .htaccess and plan replacement; (3) if attacks are recorded, remove the plugin immediately. A compromise between functionality and security is impossible here.

How does WPScan differ from other WordPress scanners?

WPScan is the only scanner with a dedicated vulnerability research database existing for over ten years. Alternatives like WPSeku enumerate plugins from a static list without detailed CVE cards. WPScan is supported by Automattic through a partnership with Jetpack, guaranteeing long-term project development.

What to choose: CLI, Docker, or SaaS

The choice depends on your tasks. Quick summary:

• If you have one site and need a one-time check, use Docker: one command, zero dependencies.
• If you have more than ten sites and need regular reports, Ruby gem in a cron job will handle it.
• If you're an agency with a hundred client sites, a WPScan SaaS subscription will remove the monitoring headache.

Don't forget the API token, without it you see only half the picture. Start with three commands from the "Quick overview" block above. Half a minute, and you know exactly if the site has open vulnerabilities. What security tool has helped you in practice, write in the comments.