Friday, October 30, 2015

WPScan: Stop feeling vulnerable about WordPress


WordPress is the most popular content management system (CMS) on the planet today. You can customize the look and feel of a WordPress website using third-party themes. If you want a functionality not offered by the WordPress core, you will most likely find a third-party plugin that satisfies your requirement. With the plethora of themes and plugins comes a major challenge in assuring their quality. Intruders can potentially exploit the vulnerabilities in poorly designed themes and plugins to gain unauthorized access to a WordPress website.

WPScan is a WordPress vulnerability scanner that is free for non-commerical use. It scans your WordPress website and reveals any known vulnerabilities in the installed plugins and themes.

The rest of this post explains how to install and run WPScan.


WPScan comes pre-installed on only a handful of lesser-known Linux distributions. If you run Debian, Ubuntu, Centos or Fedora, you must download the WPScan source and build it yourself. Because WPScan is written in Ruby, to build WPScan, you need to install the Ruby development environment.

Your first decision is to select a machine on which to build WPScan. This is the machine you use to launch WPScan later. Note that you can (and should) run WPScan on a different machine than the WordPress host. The examples in this post are based on a Debian 8.2 machine, aka Jessie.

Your next decision is how you will install the Ruby development environment, including the supporting development libraries. The WPScan website outlines 2 ways to install the necessary development environment on a Debian server: the Debian package management system and the Ruby Version Manager(RVM).

RVM is the WPScan-recommended method. It allows you to install multiple, self-contained Ruby environments on the same system. RVM puts a dedicated Ruby environment under your Home directory (e.g., /home/peter/.rvm). You can find the RVM procedure on the WPScan home page. I've followed the steps, and it works as advertised.

I opted instead for the Debian package manager method because it is a shorter procedure and I did not need the versatility (and the complexity) that RVM offers.

Below are the steps to install WPScan using the Debian package manager. The procedure is largely based on what is on the WPScan home page. I've added a couple of missing packages that are actually required.

  1. Update your Debian repository.

    $ sudo apt-get update

  2. Install the supporting development packages.

    $ sudo apt-get install git make gcc ruby ruby-dev libcurl4-openssl-dev zlib1g-dev

  3. Download the WPScan source.

    $ cd; git clone

  4. Install WPScan.

    $ cd wpscan
    $ sudo gem install bundler
    $ bundle install --without test --path vendor/bundle


The WPScan development team maintains a WordPress vulnerability database. Before you scan your WordPress website, you should first update the local copy of the vulnerability database as follows:

$ cd $HOME/wpscan
$ ruby wpscan.rb --update

To scan a WordPress website for vulnerabilities, use the following general WPScan command sequence.

$ cd $HOME/wpscan
$ ruby wpscan.rb --url --enumerate <options>


  • The --url parameter specifies which WordPress website to scan.

  • The --enumerate parameter specifies which WordPress components to scan for vulnerabilities. I use the following options:
    * vp: Scan only vulnerable plugins.
    * vt: Scan only vulnerable themes.
    * u: Scan users.
    * tt: Scan timthumbs.
    You can combine multiple options with separating commas.
    For example, --enumerate vp,vt,u

  • For further on-line help, run this command:

    $ ruby wpscan.rb --help

Results Analysis

I invoked WPScan to scan the WordPress website deployed on my desktop (localhost). The report is displayed below. Note that the output has been abbreviated in order to improve its overall readability.

WPScan managed to find:

  1. 3 vulnerabilities in the WordPress core.

    Those vulnerabilities were fixed in the most recently released version of WordPress.

  2. 1 vulnerability in the WP Super Cache plugin.

    Again, the vulnerability was fixed in the most recently released version of the plugin.

  3. No known vulnerability in the installed themes.

$ ruby wpscan.rb --url localhost --enumerate vp,vt  
[+] WordPress version 4.3 identified from meta generator    
[!] 3 vulnerabilities identified from the version number    

[!] Title: WordPress <= 4.3-Authenticated Shortcode Tags Cross-Site Scripting (XSS)    
[i] Fixed in: 4.3.1    

[!] Title: WordPress <= 4.3-User List Table Cross-Site Scripting (XSS)    
[i] Fixed in: 4.3.1    

[!] Title: WordPress <= 4.3-Publish Post and Mark as Sticky Permission Issue    
[i] Fixed in: 4.3.1      
[+] Enumerating installed plugins (only ones with known vulnerabilities)...   
[+] We found 1 plugins:  

[+] Name: wp-super-cache - v1.4.4  
[!] The version is out of date, the latest version is 1.4.6  

[!] Title: WP Super Cache <= 1.4.4 - Cross-Site Scripting (XSS)  
[i] Fixed in: 1.4.5  

[+] Enumerating installed themes (only ones with known vulnerabilities)...  
[+] No themes found  


WPScan is an important tool in your defense against possible attacks on your WordPress websites. It is recommended that you schedule WPScan to run regularly to detect known WordPress vulnerabilities. Yet, running WPScan is only half of your job. You remain vulnerable until you patch the vulnerabilities.

In general, the WordPress community fixes most known vulnerabilities and distributes the fixes quickly after the vulnerabilities are first reported. It is important that you keep your WordPress core and the third-party themes and plugins up-to-date. If your WordPress platform is up-to-date, WPScan will most likely return a clean report, and you can stop feeling vulnerable about your WordPress website.

Below are my other posts on WordPress: