Offline WordPress Scanners: What They Find and What They Don't

WPScan's free tier is one API call per plugin. The standard answer is to go offline, and there are three good ones: CMSmap, Nuclei, and Wapiti. All three are maintained. All three work without a hosted API.

They differ in one way that matters more than feature lists, and it is not usually discussed: what each tool tells you when it has no data for a plugin.

1. The problem with a clean result

Every scanner here correlates detected plugin versions against an advisory database. That correlation fails silently. If a plugin's slug is missing from the database, the tool has nothing to match, finds nothing, and reports the plugin as clean.

Plugin detected:   jetpack 10.0
Advisory lookup:   no match in database
Reported:          clean

The scan looks identical whether the plugin genuinely has no known issues or the database has never heard of it. There is no way to tell from the output.

This matters more than usual for the WordPress plugin ecosystem. Slugs are not the display names, they are not stable across rebrands, and advisory feeds lag new releases by weeks. Any database will have holes. The question is whether the tool admits which ones.

2. How each tool sources advisory data

Wordfence is the deepest free source of WordPress-specific advisories, which is why FenrirLVX converts it into vuln_db.json rather than shipping a hand-edited list. The conversion is a documented step:

# pull current advisories, convert, done
WORDFENCE_API_KEY=... go run ./tools/fetch
go run ./tools/convertor.go
./fenrir -t https://target

The 158 MB Wordfence export is not committed and is not shipped. It is an input, not a deliverable. Release archives contain the binary, the 10 MB database, and a checksum file, which keeps a platform archive around 5 MB instead of 17 MB.

3. What each tool does with a missing slug

This is the whole difference. From FenrirLVX:

[+] staging.example.com Clean
    database coverage  3/7 plugins matched  4 with no advisory data

[!] staging.example.com  confidence=78/100
    plugins  akismet 4.1, jetpack 10.0, woocommerce 7.4
    database coverage  3/7 plugins matched  4 with no advisory data
    [!] CVE-2023-1234  akismet  5.0-6.0  CVSS 7.5

A clean verdict now tells you the scanner only had data for three of seven plugins. That is the difference between a result you can act on and a result you can only hope about.

4. Where each tool is genuinely better

This comparison is not a ranking. Three of these are better than FenrirLVX at their actual job.

• CMSmap covers Joomla, Drupal and Moodle as well as WordPress, and draws from Exploit-DB, which reaches exploits that never received a CVE. If you run anything other than WordPress, it is the better first tool.
• Nuclei is a scanner platform, not a CMS auditor. It finds things a CMS-specific tool will never look for, because you can write a template for anything. FenrirLVX only knows about plugins, themes and CVEs.
• Wapiti is a general web application scanner. Misconfiguration, injection classes, and other server-side issues are outside what any of the CMS tools look for.

FenrirLVX is narrower: WordPress plugin and theme versions, correlated against a database it can rebuild from Wordfence on demand, with coverage stated in every result.

5. Running them together

They are complementary rather than competing. A defensible order, roughly:

# 1. broad coverage
nuclei -l wordpress-templates.txt -u https://target

# 2. what Nuclei cannot express: per-plugin CVE correlation
fenrir -t https://target          # prints its database coverage line

# 3. non-WordPress surfaces
cmsmap -d https://target        # Joomla, Drupal
wapiti -u https://target        # general web vulns

# 4. diff the attack surface between runs
surfacediff snap -l subs
surfacediff diff -l subs

6. What none of them do

All four correlate versions against a database. None of them tells you whether the version they read off the target is trustworthy, whether an advisory had no upper bound so it matched everything, or whether the match was made on a version they could not actually parse.

FenrirLVX flags the second case and reports the third. A finding now carries the detected version, the range it fell in, and whether that range was unbounded, so a reader can discount a match that fired because the advisory was open-ended.

7. Choosing

FenrirLVX is MIT licensed and the database is rebuildable from a Wordfence key in one command, so the tool does not rot when its data does.