How to Scan Your WordPress Site for Known Vulnerabilities

Your WordPress site could have a known, exploitable vulnerability right now and you would never know unless you actively check. Vulnerability databases like the WPScan Vulnerability Database and the National Vulnerability Database (NVD) catalog thousands of WordPress-specific CVEs, and automated scanners can match your installed versions against those records in seconds.

This guide walks through scanning your WordPress site from the outside in, starting with quick automated checks and building toward a thorough manual audit. By the end, you will have a repeatable process you can schedule weekly.

Why Scanning Matters More Than You Think

Most site owners assume that keeping WordPress updated is enough. It is not. Here is why:

• Update delays – even a 48-hour delay between a patch release and your update creates a window. Attackers monitor plugin changelogs and write exploits within hours of disclosure.
• Abandoned plugins – plugins removed from the WordPress.org repository may still be installed on your site. They will never receive another update, but their vulnerabilities remain.
• Zero-day gaps – some vulnerabilities are disclosed before a patch exists. Scanning tells you to deactivate the affected component immediately.

For the full security picture, scanning is just one part of a broader hardening process. See our complete WordPress Security Hardening Checklist for the other layers you need.

Step 1: Run an Automated External Scan

Start with a non-intrusive scan from outside your site. Our WordPress Security Scanner checks your site's publicly visible fingerprints against vulnerability databases. Enter your URL and the scanner will:

1. Detect your WordPress core version from the meta generator tag and readme.html
2. Enumerate visible plugins by checking known paths like /wp-content/plugins/{name}/readme.txt
3. Enumerate visible themes from the page source and /wp-content/themes/
4. Match detected versions against the WPScan vulnerability database
5. Check for exposed sensitive files (wp-config.php, .htaccess, debug logs)

This external scan catches the most critical issues in under a minute. However, it cannot see plugins that suppress their version numbers or are only active on specific pages.

Step 2: Enumerate Plugins and Themes Internally

For a thorough scan, you need to check every installed component, not just the ones visible from the outside. Connect to your server via SSH or WP-CLI and run:

# List all installed plugins with their versions and update status
wp plugin list --format=table

# List all installed themes
wp theme list --format=table

# Check for available updates
wp plugin update --all --dry-run
wp theme update --all --dry-run

Export the plugin and theme list. For each component, cross-reference its version against:

• The WPScan Vulnerability Database
• The CVE Details database
• The plugin's own changelog for mentions of security fixes

Step 3: Verify WordPress Core Integrity

WP-CLI includes a checksum verification command that compares every core file against the official WordPress.org checksums:

wp core verify-checksums

If any core file has been modified, WP-CLI will report it. Legitimate modifications are rare; any reported change should be investigated as a potential backdoor.

Common locations where backdoors are injected into core files:

• wp-includes/version.php
• wp-includes/load.php
• index.php (root and wp-admin)
• wp-blog-header.php

Step 4: Scan JavaScript Dependencies

WordPress themes and plugins frequently bundle JavaScript libraries, and those libraries have their own vulnerabilities. jQuery, Lodash, Moment.js, and dozens of others have had serious CVEs.

Use our JavaScript Vulnerability Scanner to crawl your site's frontend and identify outdated or vulnerable JavaScript libraries. This catches issues that a PHP-focused WordPress scanner will miss entirely. For a deep dive on this topic, read our guide to auditing your frontend JavaScript dependencies.

Step 5: Check Security Headers and TLS

While you are scanning, verify that your server is sending the correct security headers. Missing headers like Content-Security-Policy and X-Content-Type-Options leave your site vulnerable to XSS and content-sniffing attacks even if WordPress itself is fully patched.

Run your site through our Secure Headers Test and our SSL Certificate Checker to catch these issues.

Step 6: Establish a Scanning Schedule

A one-time scan is better than nothing, but vulnerabilities are disclosed continuously. Set up a recurring schedule:

• Weekly: run the external WordPress Security Scanner against all your sites
• Weekly: run wp plugin list and compare against vulnerability databases
• Monthly: run wp core verify-checksums and the JavaScript Vulnerability Scanner
• After every incident: full scan of all layers

Automate what you can. Use cron to run WP-CLI commands and send email alerts when issues are found. Many hosting providers offer built-in vulnerability scanning as well.

What to Do When You Find a Vulnerability

When a scan identifies a vulnerable component, your response depends on severity:

1. Critical or High severity (CVSS 7.0+): update or deactivate the component immediately. Do not wait for a staging test. A compromised production site is worse than a briefly broken feature.
2. Medium severity (CVSS 4.0–6.9): update within 48 hours. Test on staging first if possible.
3. Low severity (CVSS below 4.0): update during your next regular maintenance window.
4. No patch available: deactivate the plugin and find an alternative. A known unpatched vulnerability is an open invitation to attackers. See our analysis of how attackers exploit outdated plugins for real-world examples of what happens when this step is skipped.