a close up of a computer screen with a map of the world on it

WP Probe: Enumerating WordPress Plugins with Kali Linux

This blog runs on WordPress, which makes WP Probe a particularly relevant addition to Kali Linux 2026 to actually understand rather than skim past: it’s a purpose-built enumeration tool for exactly the platform this site itself is built on, aimed at identifying installed plugins and themes and flagging known vulnerabilities in them – the same job WPScan has done for years, approached from a different angle.

What WP Probe actually enumerates

Rather than relying purely on version strings pulled from readme.txt files (which plenty of hardened WordPress sites strip or fake), WP Probe fingerprints plugins and themes through a combination of static asset paths, REST API route disclosure, and behavioural checks against known plugin file structures. That makes it noticeably better than older enumeration approaches at spotting plugins whose obvious version markers have been deliberately hidden.

# basic scan against a target you own or have written authorisation to test
wp-probe -u https://example.com

# enumerate plugins specifically, with vulnerability correlation
wp-probe -u https://example.com --plugins --vuln-check

# enumerate themes and cross-reference against a local CVE feed
wp-probe -u https://example.com --themes --vuln-db /path/to/wpvulndb.json

Vulnerability correlation is the actual value-add

Finding out a site runs Plugin X version 3.2 is only half the job – the useful output is knowing whether 3.2 has a disclosed vulnerability at all. WP Probe’s vulnerability-correlation step checks detected plugin/theme versions against known-CVE data automatically, turning a plain enumeration scan into a prioritised list of “these are the plugins actually worth investigating further” rather than a flat inventory you have to cross-reference by hand afterwards.

How it compares to WPScan

  • WPScan – the long-established tool, strong plugin/theme database, well-documented, the default first choice for most WordPress engagements
  • WP Probe – newer, leans more heavily on behavioural fingerprinting over version-string parsing, which helps against sites that deliberately obscure version markers
  • In practice, running both and comparing results catches more than either alone – they miss slightly different things because they fingerprint differently

Running it against your own WordPress site

The genuinely useful application of this tool for most readers isn’t offensive at all – it’s pointing it at your own site to see what an attacker’s first automated pass would find. If WP Probe can enumerate a plugin you forgot you had installed and flag it as vulnerable, that’s a concrete, actionable finding rather than a hypothetical one:

  1. Run a full scan against your own domain, with authorisation being trivially satisfied since it’s your own site
  2. Cross-reference any flagged plugin against its changelog – a lot of “vulnerable” hits are already patched in a version you haven’t updated to yet
  3. Deactivate and delete plugins that show up as installed but aren’t actually in active use – the biggest single risk reduction most sites can make in one sitting
  4. Re-run periodically rather than once – new CVEs get disclosed against existing plugins constantly, so this isn’t a one-time check

The scope reminder that actually matters here

Only ever run WP Probe, WPScan, or any enumeration tool against a WordPress site you own or have explicit written authorisation to test – scanning someone else’s site without permission is unauthorised access regardless of how passive the scan feels. For anyone maintaining a WordPress site professionally, though, treating your own site as the target on a recurring basis is exactly the kind of low-effort, high-value check that catches the forgotten-plugin problem before someone less well-intentioned does.

Building it into a routine, not a one-off

The output is only as useful as how often you actually look at it. A single scan tells you where you stand today; the value compounds when it’s scheduled – a monthly cron job piping WP Probe’s output to a file you diff against last month’s is enough to catch a newly disclosed CVE against a plugin you already have installed, often well before an automated botnet gets around to trying it. That’s the same discipline the exposure-management and vulnerability-management vendor tools covered elsewhere on this blog are built around at enterprise scale; WP Probe just gives a single WordPress site the same idea for free.


Leave a Reply