-
Notifications
You must be signed in to change notification settings - Fork 1.3k
WPScan User Documentation
WPScan is a free, for non-commercial use, black box WordPress vulnerability scanner written for security professionals and blog maintainers to test the security of their sites.
WPScan is written in the Ruby programming language. The first version of WPScan was released on the 16th of June 2011.
WPScan is shipped as a Ruby gem, and can be installed with the following command:
gem install wpscan
We also support Docker. Pull the repo with:
docker pull wpscanteam/wpscan
Example Docker command to enumerate usernames:
docker run -it --rm wpscanteam/wpscan --url https://example.com/ --enumerate u
brew install wpscan
To update the WPScan software:
gem update wpscan
To update WPScan in Kali Linux:
apt-get update && apt-get upgrade
WPScan keeps a local database of metadata that is used to output useful information, such as the latest version of a plugin. The local database can be updated with the following command:
wpscan --update
Please note that this data does not include the vulnerability data. See Vulnerability Database for information on the vulnerability data.
When enumerating the WordPress version, installed plugins or installed themes, you can use three different "modes", which are:
- passive
- aggressive
- mixed
If you want the most results use the "mixed" mode. However, if you are worried that the server may not be able to handle a large number of requests, use the "passive" mode. The default mode is "mixed", with the exception of plugin enumeration, which is "passive". You will need to manually override the plugin detection mode, if you want to use anything other than the default, with the --plugins-detection option.
WPScan can enumerate various things from a remote WordPress applcation, such as plugins, themes, usernames, backed up files wp-config.php files, Timthumb files, database exports and more. To use WPScan's enumeration capabilities supply the -e option.
The following enumeration options exist:
-
vp(Vulnerable plugins) -
ap(All plugins) -
p(Popular plugins) -
vt(Vulnerable themes) -
at(All themes) -
t(Popular themes) -
tt(Timthumbs) -
cb(Config backups) -
dbe(Db exports) -
u(User IDs range. e.g: u1-5) -
m(Media IDs range. e.g m1-15)
If no option is supplied to the -e flag, then the default will be: vp,vt,tt,cb,dbe,u,m
Here we have put together a bunch of common commands that will help you get started quickly.
Get your API token from wpvulndb.com if you also want the vulnerabilities associated with the detected plugin displaying.
- For all plugins with known vulnerabilities:
wpscan --url example.com -e vp --plugins-detection mixed --api-token YOUR_TOKEN
- For all plugins in our database (could take a very long time):
wpscan --url example.com -e ap --plugins-detection mixed --api-token YOUR_TOKEN
- Password brute force attack
wpscan --url example.com -e u --passwords /path/to/password_file.txt
WPScan uses the WordPress Vulnerability Database API in real time to retrieve known vulnerabilities that affect WordPress core, plugins and themes.
For the vulnerability information to be shown within WPScan you will need to supply an API token with the --api-token YOUR_TOKEN option. Alternatively, you can supply the API token from a WPScan configuration file.
A free API token is available, as well as paid plans, depending on your usage needs.
If you do not supply an API token, WPScan will work as normal, with the exception that when a WordPress version, plugin or theme is detected, the associated known vulnerabilities will not be displayed.
To bypass some simple WAFs you can try the --random-user-agent option.
If WPScan is not working as expected, you can use the --proxy option, and use a web proxy to inspect WPScan's HTTP requests, and the remote server's HTTP responses. This is useful when you do not know why you are getting false positives, or false negatives.
We blog here - https://blog.wpscan.org/
We tweet here - https://twitter.com/_wpscan_