This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.
A vulnerability scan is mostly a lookup. The tool works out which software a site runs and which versions, then checks that list against a database of known flaws. So I did the lookup by hand. On 25 October 2026 I took the 25 plugins installed on this site (the sister site, repairpicks.com, runs the identical 25) and checked each one against two public vulnerability databases, WPScan and Patchstack. WPScan listed 67 known vulnerabilities across them and Patchstack 69. None of them affected the version I have installed.
That clean result is the least interesting part. The useful part is what the lookup needed to be correct, where the two databases disagreed, and why the free scanners that skip the lookup cannot tell you any of this.
What a “vulnerability scan” can mean
Four different tools get that name, and they answer different questions:
| Kind of check | Example | What it sees | What it misses |
|---|---|---|---|
| Remote surface scan | Sucuri SiteCheck | What a visitor’s browser loads: injected code, blacklist status, outdated server software | Most of the software inside WordPress. It named 0 plugins across 71 scans in my last survey |
| Version lookup | WPScan and Patchstack plugin pages, or the free Jetpack Protect plugin | Known flaws in the exact plugin and theme versions you run | Anything not yet disclosed, and your own custom code |
| Passive crawl | OWASP ZAP baseline scan | Weak headers, cookie flags and similar problems in the pages it crawls | Flaws that only show up when the site is attacked |
| Active scan | OWASP ZAP full scan | Injection and similar flaws, found by sending attack requests | Nothing on purpose, but it is slow and noisy |
I ran the first two kinds. I did not run ZAP, so what follows about it comes from its documentation. The baseline script runs the ZAP spider, waits for passive scanning to finish and, in the documentation’s words, does not perform actual attacks. The spider runs for one minute by default. The full-scan script does the opposite: its page says it runs a full active scan and warns that it does perform actual attacks and may run for a long time, with no spider time limit unless you set one. Only point either at a site you own or have written permission to test, and check your host’s rules first, because an active scan sends a lot of hostile-looking traffic.
How I checked the 25 plugins
- Listed what is installed. I read the plugin list and versions through the WordPress REST API: 25 plugins on each site, 24 active and 1 inactive.
- Looked up each plugin’s public page on WPScan and on Patchstack. Both identify a plugin by its folder name, for example
litespeed-cache. - Compared the version. Each WPScan entry has a “fixed in” version. I compared it to the installed version: if mine is lower, the entry applies to me. Patchstack summarises the same thing as a count of present and patched issues.
WPScan’s free API allows 25 calls per day for non-commercial use, and its pricing page says commercial use needs a paid licence. I only read the public plugin pages, one request each, but if you plan to automate this on a site that earns money, read their terms first.
What the two databases said
| Measure (25 plugins) | Result |
|---|---|
| Plugins with at least one known entry in WPScan | 13 |
| Plugins with no entry in WPScan | 12 |
| Entries in WPScan, total | 67 |
| Entries in Patchstack, total | 69 |
| Entries that apply to the installed versions | 0 in both (WPScan by version comparison, Patchstack “0 present” on every page that showed a count) |
- Most of the history is old and mixed in severity. WPScan’s scores for the 67 were 1 critical, 16 high, 33 medium, 12 low and 5 unscored. 16 were published in 2026 and 16 in 2024. The critical one is a 2020 privilege escalation in Site Kit by Google, fixed in version 1.8.0, and I run 1.190.0.
- One plugin supplies nearly four in ten of the entries. LiteSpeed Cache has 26 of the 67 WPScan entries. Of the 10 entries published between 27 August and 21 October, 7 are LiteSpeed’s, 2 are Code Snippets and 1 is Site Kit. Three of the LiteSpeed entries are dated 21 October, four days before my check, and WPScan lists all three as fixed in 7.9.2, which is the version installed. That is the point of the exercise: the answer changed within a week, and a lookup from a month ago would have missed it.
- A long list is not the same as a risky plugin. The count reflects how closely researchers look at a plugin as much as how it is written. Heavily installed plugins attract more attention, and a plugin with an empty list may simply be examined less.
Where the two databases disagreed
For 17 of the 25 plugins the totals matched. For the other 8 they differed by one or two:
| Plugin | WPScan | Patchstack |
|---|---|---|
| Complianz (premium) | 2 | 4 |
| Easy Table of Contents | 5 | 6 |
| Export All URLs | 7 | 5 |
| Instant Images | 3 | 4 |
| LiteSpeed Cache | 26 | 27 |
| Redirection | 6 | 5 |
| Simple Author Box | 2 | 3 |
| Disable Comments | 1 | 0 |
I would not read a difference as a missing flaw. Databases split one disclosure into several entries or merge several into one, and each credits different researchers. Patchstack’s pages for 10 of the plugins showed no counts at all, which I treated as zero, and WPScan also showed zero for all 10. The practical lesson is smaller: if a scanner says a plugin is clean, ask which database it reads. The free Jetpack Protect plugin, for example, describes itself as powered by WPScan and scans daily for known vulnerabilities in your WordPress version, plugins and themes, while its paid tier adds malware scanning and a firewall.
Why a remote scan cannot do this
Everything above depends on knowing the exact version of each plugin. A scanner outside your site has to guess it. On this site, the page source names 4 of the 24 active plugins, and a plugin’s readme.txt opened for 22 of 24 when I tested it, as I covered in the theme and plugin detection survey. My malware scan survey found that the free scanner listed no plugin on either site. A tool that cannot name the software cannot match it against a list of flaws, so a clean remote report says nothing about your plugins.
How to run this check on your own site
- Get the list. Open Plugins in the dashboard, or run
wp plugin listif you have WP-CLI. Note the version of every plugin and theme, active or not. - Find the folder name. It is the directory under
wp-content/plugins, usually the plugin’s slug on WordPress.org. - Look each one up on the WPScan and Patchstack pages for that name. Titles start with the lowest account level that can trigger the flaw: “Unauthenticated” means any visitor, “Subscriber+” means someone with a free account.
- Compare the “fixed in” version with yours. Lower means you are affected. Update first, then read the details.
- Repeat on a schedule. LiteSpeed Cache collected three entries in a single day, so a one-off check ages fast. Monthly by hand, or daily through a plugin such as Jetpack Protect, is a sensible range. WordPress can also update individual plugins automatically from the Plugins screen.
- Keep a restore point. An update that breaks the site is easier to undo with a backup in hand, and this guide covers choosing the restore route.
What this lookup does not prove
- A flaw nobody has reported yet. The databases hold disclosed issues only. Zero known is not zero.
- Lag. An entry appears after a researcher reports it and the database processes it. For a few days a flaw can be real and unlisted.
- Your own code. A snippet pasted into a theme or a Code Snippets entry is in no database.
- Premium and custom plugins. Complianz’s premium edition appears in both databases here, but a premium plugin sold outside WordPress.org may be tracked less closely.
- The rest of the stack. Server software, weak passwords and missing response headers sit outside a plugin lookup. My guide to checking your website’s security headers covers one of those layers.
Checked for accuracy on 25 October 2026. The plugin list was read from this site and its sister site on 25 October 2026 through the WordPress REST API, and each plugin’s public WPScan and Patchstack page was fetched once that day. Entry counts, severity scores and “fixed in” versions are as the pages showed them and change as new disclosures are added. ZAP behaviour was checked against its documentation, and the WPScan API limit against its pricing page, not by running either.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.