WPScan

WordPress Security Scanner

WPScan WordPress Vulnerability Database - WordPress Security Plugin

INSTALL

Prerequisites

• (Optional but highly recommended: rbenv)
• Ruby >= 3.3 - Recommended: latest stable
• Curl >= 7.72 - Recommended: latest stable
  • 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 stable
• 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 distribution (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

WPScan depends on gems with native extensions (e.g. yajl-ruby, nokogiri, ffi), so a working C toolchain and Ruby development headers must be present before gem install wpscan. Without them, the install fails with errors like Failed to build gem native extension or make: x86_64-linux-gnu-gcc: No such file or directory (see #1844).

• Debian / Ubuntu:

  sudo apt install build-essential ruby-dev
  

• Fedora / RHEL / CentOS:

  sudo dnf install @development-tools ruby-devel
  

• Arch Linux:

  sudo pacman -S base-devel ruby
  

• Alpine:

  sudo apk add build-base ruby-dev
  

• macOS: install the Xcode Command Line Tools (xcode-select --install).

Then install the gem:

gem install wpscan

On MacOSX, if a Gem::FilePermissionError is raised due to 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 -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --url https://target.tld/ --enumerate u

Enumerating a range of usernames

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

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

Persisting the local database

The image ships with a copy of the local database baked in at build time. Because the example commands above use --rm, any database update performed during a run is discarded when the container exits, so the next run starts again from the (potentially stale) baked-in copy.

Mounting a named volume at /wpscan/.cache/wpscan/db (the wpscan user's cache directory inside the container) keeps the database across runs, so wpscan --update only re-downloads files whose checksums actually changed and the 5-day staleness prompt behaves as it would for a local install:

docker run -it --rm -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --update

The named volume is created automatically on first use if it doesn't already exist.

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. It performs version detection, theme detection, and interesting findings discovery. To enumerate plugins, themes, users, backup folders, etc., use the -e option (e.g., -e ap for all plugins, -e vp for vulnerable plugins, -e bf for backup folders).

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)

Database Location

The database location follows the XDG Base Directory Specification:

• New installations: ~/.cache/wpscan/db (or $XDG_CACHE_HOME/wpscan/db if set)
• Existing installations: ~/.wpscan/db (legacy path, maintained for backward compatibility)

Runtime files such as the default HTTP cache and cookie jar are stored under $TMPDIR/wpscan when $TMPDIR is set. Otherwise they use the same per-user XDG cache directory, for example ~/.cache/wpscan/cache and ~/.cache/wpscan/cookie_jar.txt. These defaults can be overridden with --cache-dir and --cookie-jar.

To migrate an existing installation to the XDG path:

mv ~/.wpscan ~/.cache/wpscan

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.

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 the installed theme.
• On average, a WordPress website has 22 installed plugins.

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):