Running a vulnerability scan against a live WordPress site is a bad idea if you have not tested the scan first. Aggressive plugin enumeration, brute-force checks, and directory busting can knock a small server over, trip a firewall rule that locks you out of your own dashboard, or leave a pile of junk log entries for your host’s abuse team to ask about. The fix is simple: build a disposable WordPress install inside VirtualBox, point your scanning tools at that instead, and only take what you learn to the real site.
This guide walks through the full setup: installing VirtualBox, standing up a LAMP stack on Ubuntu inside the VM, installing WordPress, and running three different scanners against it: WPScan, Nikto, and OpenVAS. Each catches different things. Using just one gives you a partial picture.
Why a Virtual Machine Instead of a Staging Site
Staging sites still live on shared infrastructure most of the time, and scanning tools generate a lot of traffic that looks identical to an actual attack from your host’s perspective. A local VM sidesteps that entirely. Nothing you do inside VirtualBox touches your production database, your production IP reputation, or anyone else’s server.
There is a second reason this matters: reproducibility. Once you have a VM configured with a known-vulnerable WordPress setup, you can snapshot it. Break something during testing, and you roll back in under a minute instead of rebuilding from scratch.
Step 1: Install VirtualBox
Download VirtualBox from virtualbox.org for your host operating system. Windows, macOS, and Linux builds are all available and free. Run the installer, accept the network interface warning if one appears (VirtualBox needs to briefly reset your network adapters to add its own virtual ones), and open the app once it finishes.
Two settings matter before you create anything. First, go to File > Host Network Manager and confirm a NAT network or host-only adapter exists. You will want this later if you plan to access the VM from tools running on your host machine rather than inside the VM itself. Second, check how much free RAM and disk your host has. A comfortable WordPress + scanning setup wants at least 4 GB of RAM allocated to the VM and 20 GB of disk, more if you plan to run OpenVAS, which is resource-hungry on its own.
Step 2: Create the Virtual Machine
- Click New in VirtualBox.
- Name it something identifiable, like “WP Security Lab.”
- Set the type to Linux and version to Ubuntu (64-bit).
- Allocate at least 2 GB of RAM for a basic setup, 4 GB if you intend to install OpenVAS.
- Create a virtual hard disk, VDI format, dynamically allocated, at least 20 GB.
Download the Ubuntu Server or Desktop ISO from ubuntu.com. Server is lighter and fine for this purpose since you will interact with everything through a terminal and a browser anyway. Attach the ISO under Settings > Storage, start the VM, and walk through the standard Ubuntu installer: keyboard layout, disk partitioning (accept the defaults unless you have a reason not to), and a user account. Skip the optional snap packages the installer offers during setup; you do not need them here and they add install time.
Step 3: Build the LAMP Stack and Install WordPress
Once you are logged into the fresh Ubuntu install, open a terminal and update the package index first.
sudo apt update && sudo apt upgrade -yInstall Apache, MySQL, and PHP together:
sudo apt install apache2 mysql-server php libapache2-mod-php php-mysql php-xml php-curl -ySecure the MySQL installation and set a root password when prompted:
sudo mysql_secure_installationCreate a database and a dedicated user for WordPress rather than using root. This mirrors what you should be doing in production anyway, so it is good practice to carry into your test environment.
sudo mysql -u root -pCREATE DATABASE wordpress;
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'a-real-password-here';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;Download and unpack WordPress, then move it into the Apache web root.
wget https://wordpress.org/latest.tar.gz
tar -xvzf latest.tar.gz
sudo mv wordpress/* /var/www/html/
sudo chown -R www-data:www-data /var/www/html/
sudo chmod -R 755 /var/www/html/Open a browser inside the VM (or from your host, if you configured port forwarding on the NAT adapter) and navigate to the VM’s local address. Complete the five-minute WordPress installer, enter the database name and user you just created, and finish setup.
One thing worth doing deliberately here: install an older, known-vulnerable plugin version on purpose. WPScan’s database is most useful when there is something for it to actually find. Pulling an outdated version of a plugin from the WordPress.org SVN archive gives your scan something real to report instead of a clean “no vulnerabilities found” result that teaches you nothing about how the tool behaves.
Step 4: Install and Run the Scanners
WPScan
WPScan is purpose-built for WordPress and checks core version, plugins, themes, usernames, and known CVEs against a maintained vulnerability database. Install it via Ruby’s gem package manager:
sudo apt install ruby ruby-dev build-essential -y
sudo gem install wpscanWPScan’s vulnerability database requires a free API token from wpscan.com. The free tier gives you 25 requests a day, which is plenty for testing a single site repeatedly. Register the token once:
wpscan --api-token YOUR_TOKEN_HERE --url http://localhost --updateRun a full scan that enumerates plugins, themes, and users:
wpscan --url http://localhost --enumerate vp,vt,u --api-token YOUR_TOKEN_HEREThe output lists each detected plugin with its version, flags anything with a known CVE, and rates severity. If you installed that deliberately outdated plugin from the previous step, you should see it show up here with a CVE reference and a link to details.
Nikto
Nikto checks the web server itself rather than WordPress specifically: outdated Apache modules, dangerous default files, missing security headers, directory listing left enabled. It complements WPScan rather than duplicating it.
sudo apt install nikto -y
nikto -h http://localhostExpect a long list of findings, most of them informational rather than critical. Nikto is deliberately noisy; it flags things worth knowing about even when they are not exploitable on their own, like server version disclosure in HTTP headers.
OpenVAS
OpenVAS (now packaged as Greenbone Vulnerability Manager in newer distributions) is a full network vulnerability scanner, not a web-app-specific tool. It is heavier to install and run than the other two, and honestly overkill if your only target is one WordPress install, but it is worth knowing about if you are also checking the underlying server for open ports, weak TLS configuration, or outdated system packages.
sudo apt install openvas -y
sudo gvm-setupThe setup script downloads several gigabytes of vulnerability feed data on first run, which can take well over an hour depending on connection speed. Once it finishes, gvm-setup prints an admin password. Save it, because it will not show it again. Access the web interface at https://localhost:9392 and run a full and fast scan against your VM’s own IP address.
Reading and Acting on the Results
The three tools together typically surface the same handful of categories, over and over, across real WordPress installs:
Outdated plugins and themes account for the majority of confirmed vulnerabilities WPScan reports. This is the single biggest lever you have. A plugin that has not shipped an update in two years is worth removing even if no CVE has been filed against it yet, because nobody is fixing anything in it.
Weak or default credentials show up constantly in WPScan’s username enumeration results, especially on sites still running an “admin” account. Rename it and enforce strong passwords across every admin account, then add a login attempt limiter.
Missing security headers (X-Frame-Options, X-Content-Type-Options, a reasonable Content-Security-Policy) get flagged by Nikto and cost nothing to fix. Most caching or security plugins can set these for you, or you can add them directly in your server config.
File and directory permission issues turn up more often than people expect, usually from a bad migration or a plugin that changed permissions during install and never reverted them. `755` for directories and `644` for files is the standard baseline; anything more permissive is worth investigating.
Common Mistakes When Running Local Vulnerability Scans
People new to this tend to make the same handful of errors.
Scanning with a clean, fully updated WordPress install and being confused when nothing shows up. If you want to learn what a real finding looks like, deliberately install an outdated component first, as described above.
Running OpenVAS with default scan configs against a low-resource VM. The full scan profile is thorough but slow and CPU-heavy; use the “Discovery” or “Host Discovery” profile first if your VM only has 2 GB of RAM.
Forgetting to update the WPScan vulnerability database before scanning. The database is updated daily on wpscan.com’s end, and an install that is even a week old can miss recently disclosed CVEs. Run `wpscan –update` before every session, not just the first one.
Treating a clean scan as proof of security. Scanners only catch known, signature-based issues. A zero-day, a logic flaw in custom code, or a misconfigured server-side permission will not show up in any of these reports.
Turning This Into a Repeatable Habit
Once the VM is set up, the actual scanning takes minutes. Snapshot the VM right after the initial WordPress install (Machine > Take Snapshot in VirtualBox) so you can revert to a clean state before testing a new plugin or theme. This turns the whole workflow into something you can run before every plugin update on your real site: spin up the VM, restore the snapshot, install the plugin version you are about to deploy, scan it, and only then push it live.
For scanning your actual production site, none of this VM work is a substitute for a proper security plugin running continuously. Wordfence and Sucuri both do real-time malware scanning and firewall filtering that a one-off local scan cannot replicate. Think of the VM setup described here as your pre-flight check, and a security plugin as the thing watching the site around the clock afterward.
Automating Scans Inside the VM
Manually typing scan commands gets old fast if you are using this VM regularly. Cron handles the repetition. Open the crontab editor inside the VM:
crontab -eAdd a line to run WPScan every night at 2 AM and dump results to a log file:
0 2 * * * wpscan --url http://localhost --enumerate vp,vt,u --api-token YOUR_TOKEN_HERE >> /home/yourusername/wpscan-log.txt 2>&1Save and exit. The scan will run unattended, and you can check the log file the next morning instead of babysitting a terminal. If you want an email notification instead of a manual log check, pipe the output through `mail` (install `mailutils` first) or write a small shell script that greps the log for the word “Vulnerable” and only sends a message when something actually needs your attention. Nobody wants a nightly email that just says “still fine.”
This matters more than it sounds like it should. Plugin vulnerabilities get disclosed constantly, and the gap between disclosure and patch on a given site is often measured in weeks, not days. A nightly scan against your VM’s known plugin set catches new disclosures the same day WPScan’s database picks them up.
Choosing Between the Three Tools
None of these three replace each other, but if you only have time for one, the right pick depends on what you are actually worried about.
WPScan is the obvious first choice for anyone whose concern is specifically WordPress: outdated plugins, theme vulnerabilities, weak usernames. It is fast and its output maps directly to actionable fixes. Update this plugin, remove that theme, rename this username.
Nikto earns its place when you are less sure the problem is WordPress-specific at all. Server misconfiguration, leftover default files from a hosting control panel, exposed backup archives sitting in a public directory. These are server-level issues that WPScan will never see because it is not looking at that layer.
OpenVAS is the right call only when your responsibility extends past the WordPress install itself: open ports you did not intend to expose, outdated SSH configurations, weak TLS cipher suites. Most people using managed WordPress hosting will never need it. Anyone running their own VPS or dedicated server should.
Troubleshooting Setup Problems
A few issues come up often enough to mention directly.
WPScan installation fails with a Ruby version error. Ubuntu’s default apt repositories sometimes carry an older Ruby than WPScan’s gem requires. Installing via rbenv or rvm to get a current Ruby version resolves this, though it adds setup time.
The WordPress site loads inside the VM’s own browser but not from the host machine. This is almost always a networking mode issue. Switch the VM’s network adapter from NAT to Bridged in VirtualBox settings, or set up port forwarding under NAT settings if you want to keep NAT mode for isolation reasons.
gvm-setup hangs or fails partway through. OpenVAS’s feed sync is sensitive to interrupted downloads. Running `sudo gvm-setup` again after a failure usually resumes rather than restarting from zero, but a full re-run from scratch (`sudo gvm-setup –reinstall`, checking the exact flag for your distribution’s package version) sometimes clears a corrupted partial download faster than waiting for a resume.
MySQL refuses the WordPress installer’s connection attempt. Double check the database user’s host is set to ‘localhost’ and not ‘%’, and confirm `mysql_secure_installation` did not disable remote root login in a way that also blocked the wpuser account from connecting locally. It is a surprisingly common mix-up.
Frequently Asked Questions
Can I scan a live site directly with WPScan instead of setting up a VM?
Yes, and many security professionals do, but only against sites they own or have written permission to test. Running WPScan or any vulnerability scanner against a site you do not control or lack authorization for is illegal in most jurisdictions, regardless of intent.
Why does WPScan need an API token?
The vulnerability database itself is a paid product that WPScan’s maintainers fund through API access. The free tier’s 25 daily requests is enough for personal use and testing; heavier professional use requires a paid plan.
Is OpenVAS worth the setup time for just one WordPress site?
Not really, unless you are also responsible for the server itself, not just the WordPress install. If your hosting is fully managed, WPScan and Nikto cover the relevant surface area without the multi-gigabyte feed download and heavier resource footprint OpenVAS requires.
How often should I re-scan?
Before deploying any new plugin or theme to production. And on a recurring schedule for the live install itself, weekly is reasonable for most small to mid-size sites, using a proper security plugin rather than manual WPScan runs.
