Check WordPress Plugins for Vulnerabilities: WP-CLI, WPScan, Databases

This article is a localized edition of the Japanese original. Read the Japanese original

Plugin vulnerabilities can be exploited soon after they are disclosed. The basic routine is to know which plugins and versions you run, compare them against known vulnerabilities, and update when a fixed version is available, repeated on a regular schedule. This article walks through checking versions with WP-CLI, matching them with WPScan, reading vulnerability databases, checking for tampering, and what to do when you find a problem. Commands and pricing conditions were checked against each official documentation as of November 2026.

1. List your installed plugins and versions

First, find out what is installed and at which version. You can see this under "Plugins → Installed Plugins", but WP-CLI lets you save the list.

# Show name, version, active/inactive and whether an update exists
wp plugin list --fields=name,version,status,update

# Show only plugins with an available update
wp plugin list --update=available

# Save as JSON for your records
wp plugin list --fields=name,version,status --format=json > plugins.json

Inactive plugins also appear in the list. Even when deactivated, their files stay on the server and vulnerable files can sometimes be requested directly, so delete plugins you no longer use. The WP-CLI basics are covered in "Managing plugins with WP-CLI".

2. Match against known vulnerabilities with WPScan

WPScan is a command-line tool that examines a WordPress site from the outside. It gets vulnerability data from the WPScan API, so you create an account on wpscan.com and issue an API token.

According to WPScan's pricing page, the free plan is limited to non-commercial use and 25 API calls per day. Using it for business sites requires a paid license. WPScan runs without an API token, but then it shows no vulnerability data.

# Install with Ruby gems
gem install wpscan

# Or use Docker
docker pull wpscanteam/wpscan

# Check for plugins with reported vulnerabilities
wpscan --url https://example.com --api-token YOUR_API_TOKEN -e vp

# Use both passive and aggressive detection
wpscan --url https://example.com --api-token YOUR_API_TOKEN -e vp --plugins-detection mixed

The main values for -e are:

By default, plugin detection is passive, reading traces from the page HTML and similar sources. Plugins that leave no trace in the HTML may be missed. Specifying aggressive or mixed finds more, but also sends more requests.

Only scan sites you manage or have permission to test. For more on usage, see "Checking your site for vulnerabilities with WPScan".

3. Confirm the details in vulnerability databases

For plugins flagged by WPScan or named in security news, look up the details in these databases:

• WPScan Vulnerability Database (wpscan.com)
• Wordfence Intelligence (wordfence.com)
• Patchstack Database (patchstack.com)
• NVD (nvd.nist.gov, search by CVE number)

Check these items:

Handle issues that can be exploited without logging in, and those with high severity, first. Issues exploitable with subscriber access are urgent on sites that accept user registration (membership sites, shops and so on).

4. Check whether files have been tampered with

If a vulnerability may have been exploited, check whether the files are still as distributed. WP-CLI's verify-checksums compares files against the checksums published by WordPress.org.

# Check all plugins
wp plugin verify-checksums --all

# Check a specific plugin
wp plugin verify-checksums contact-form-7

# Check WordPress core files
wp core verify-checksums

If everything matches, you see something like Success: Verified 8 of 8 plugins. If files have been added or changed, they are listed.

Premium plugins not distributed on WordPress.org have no checksums, so this method cannot check them. In that case, download the same version from the vendor and compare the files.

5. What to do when you find a vulnerability

# If a fixed version exists: update
wp plugin update contact-form-7

# If there is no fix: deactivate, and delete if you don't need it
wp plugin deactivate vulnerable-plugin
wp plugin delete vulnerable-plugin

# Before a bulk update, preview what will be updated
wp plugin update --all --dry-run

vulnerable-plugin is an example. Replace it with the real slug (the name column of wp plugin list).

• Take a backup before updating, and afterwards confirm that key features (contact forms, payments and so on) still work.
• If no fix is released and development has stopped, consider moving to another plugin with the same features. Plugins whose distribution was stopped on WordPress.org show a closure notice on their plugin page.
• If there are signs of tampering, updating is not enough. Also check for added administrator users, PHP files placed in uploads, and changes to wp-config.php, and restore from a backup if needed.

6. Make checking a habit

• Under "Plugins" in the admin area, you can enable automatic updates per plugin (WordPress 5.5 and later). Start with plugins whose updates are unlikely to break your layout. For details, see "How to set up automatic plugin updates".
• If you run WPScan regularly from cron, keep the free plan's 25 calls per day and non-commercial condition in mind.
• The security plugin Wordfence also reports plugins that need updating and similar issues in its scans. Its usage is explained in "Scanning your site with Wordfence".

Summary

Checking plugins for vulnerabilities goes in this order: list them (wp plugin list), match against known vulnerabilities (WPScan or vulnerability databases), check for tampering (wp plugin verify-checksums), and respond by updating or deleting. Deleting plugins you don't use is the lowest-effort measure of all.

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)