Table of Contents

Wordpress Security Scanner

WPScan is a free (for non-commercial use) black box WordPress security scanner written for security professionals and bloggers to test the security of their sites.

INSTALL

Prerequisites

(Optional but highly recommended: RVM)
Ruby >= 2.5 - Recommended: latest
- Ruby 2.5.0 to 2.5.3 can cause an ‘undefined symbol: rmpd_util_str_to_d’ error in some systems, see #1283
Curl >= 7.72 - Recommended: latest
- The 7.29 has a segfault
- The < 7.72 could result in Stream error in the HTTP/2 framing layer in some cases
RubyGems - Recommended: latest
Nokogiri might require packages to be installed via your package manager depending on your OS, see https://nokogiri.org/tutorials/installing_nokogiri.html

In a Pentesting distribution

When using a pentesting distubution (such as Kali Linux), it is recommended to install/update wpscan via the package manager if available.

In macOSX via Homebrew

brew install wpscanteam/tap/wpscan

From RubyGems

gem install wpscan

On MacOSX, if a Gem::FilePermissionError is raised due to the Apple’s System Integrity Protection (SIP), either install RVM and install wpscan again, or run sudo gem install -n /usr/local/bin wpscan (see #1286)

Updating

You can update the local database by using wpscan --update

Updating WPScan itself is either done via gem update wpscan or the packages manager (this is quite important for distributions such as in Kali Linux: apt-get update && apt-get upgrade) depending on how WPScan was (pre)installed

Docker

Pull the repo with docker pull wpscanteam/wpscan

Enumerating usernames

docker run -it --rm wpscanteam/wpscan --url https://target.tld/ --enumerate u

Enumerating a range of usernames

docker run -it --rm wpscanteam/wpscan --url https://target.tld/ --enumerate u1-100

** replace u1-100 with a range of your choice.

Usage

Full user documentation can be found here; https://github.com/wpscanteam/wpscan/wiki/WPScan-User-Documentation

wpscan --url blog.tld This will scan the blog using default options with a good compromise between speed and accuracy. For example, the plugins will be checked passively but their version with a mixed detection mode (passively + aggressively). Potential config backup files will also be checked, along with other interesting findings.

If a more stealthy approach is required, then wpscan --stealthy --url blog.tld can be used. As a result, when using the --enumerate option, don’t forget to set the --plugins-detection accordingly, as its default is ‘passive’.

For more options, open a terminal and type wpscan --help (if you built wpscan from the source, you should type the command outside of the git repo)

The DB is located at ~/.wpscan/db

Optional: WordPress Vulnerability Database API

The WPScan CLI tool uses the WordPress Vulnerability Database API to retrieve WordPress vulnerability data in real time. For WPScan to retrieve the vulnerability data an API token must be supplied via the --api-token option, or via a configuration file, as discussed below. An API token can be obtained by registering an account on WPScan.com.

Up to 25 API requests per day are given free of charge, that should be suitable to scan most WordPress websites at least once per day. When the daily 25 API requests are exhausted, WPScan will continue to work as normal but without any vulnerability data. Users can upgrade to paid API usage to increase their API limits within their user profile on WPScan.com.

The Free plan allows 25 API requests per day. View the different available API plans.

How many API requests do you need?

Our WordPress scanner makes one API request for the WordPress version, one request per installed plugin and one request per installed theme.
On average, a WordPress website has 22 installed plugins.
The Free plan should cover around 50% of all WordPress websites.

Load CLI options from file/s

WPScan can load all options (including the –url) from configuration files, the following locations are checked (order: first to last):

~/.wpscan/scan.json
~/.wpscan/scan.yml
pwd/.wpscan/scan.json
pwd/.wpscan/scan.yml

If those files exist, options from the cli_options key will be loaded and overridden if found twice.

e.g:

~/.wpscan/scan.yml:

cli_options:
  proxy: 'http://127.0.0.1:8080'
  verbose: true

pwd/.wpscan/scan.yml:

cli_options:
  proxy: 'socks5://127.0.0.1:9090'
  url: 'http://target.tld'

Running wpscan in the current directory (pwd), is the same as wpscan -v --proxy socks5://127.0.0.1:9090 --url http://target.tld

Save API Token in a file

The feature mentioned above is useful to keep the API Token in a config file and not have to supply it via the CLI each time. To do so, create the ~/.wpscan/scan.yml file containing the below:

cli_options:
  api_token: YOUR_API_TOKEN

Load API Token From ENV (since v3.7.10)

The API Token will be automatically loaded from the ENV variable WPSCAN_API_TOKEN if present. If the --api-token CLI option is also provided, the value from the CLI will be used.

Enumerating usernames

wpscan --url https://target.tld/ --enumerate u

Enumerating a range of usernames

wpscan --url https://target.tld/ --enumerate u1-100

** replace u1-100 with a range of your choice.