Vexta's WordPress, Drupal and Joomla Vulnerability Scanner

A WordPress vulnerability scanner needs to identify more than the fact that a site runs WordPress. It needs the exact plugins, theme and version in use, because that is where most exploitable CVEs actually live. Vexta fingerprints WordPress, Drupal and Joomla separately, then runs a dedicated deep scan for whichever one it finds: plugin, theme, module or extension enumeration, matched against an embedded CVE database.

The problem: generic scanning misses CMS-specific risk

A large share of real-world WordPress, Drupal and Joomla compromises trace back to a third-party plugin, module or extension running an outdated, vulnerable version, not to the CMS core itself. A generic web scanner that treats the site as an undifferentiated pile of HTML and forms has no way to know that the contact form on the page is Contact Form 7 version 5.4, and that version has a known CVE.

That gap is exactly what a CMS-aware deep scan is for: once the platform is identified, testing shifts from generic checks to enumeration built specifically for how that platform organizes its plugins, themes, and version metadata. A hunter working a bug bounty program built on WordPress, Drupal, or Joomla gets more mileage from that targeted enumeration in the first ten minutes of a scan than from an hour of generic crawling.

How does Vexta identify which CMS is running?

For WordPress, Vexta checks four independent signals: the presence of /wp-login.php, a <meta name="generator" content="WordPress N"> tag, the <generator> field in the site's /feed/, and a /wp-json/ response that returns REST API namespaces. For Drupal, it looks for an X-Generator header, a reachable /CHANGELOG.txt or /core/CHANGELOG.txt, or a login form fingerprint matching Drupal's markup. For Joomla, it checks /administrator/manifests/files/joomla.xml, /language/en-GB/en-GB.xml, and the platform's own generator meta tag.

Once one of these is confirmed, Vexta triggers the matching deep scan for that CMS specifically, and everything that scan finds flows into the same proof-of-exploitation and reporting pipeline as the rest of a Vexta scan.

What does the WordPress deep scan check?

Plugin enumeration probes /wp-content/plugins/{slug}/readme.txt for the top 100 most-installed plugins, covering names like Akismet, Jetpack, Contact Form 7, Yoast, WordFence, Elementor, WPForms and LiteSpeed. Theme enumeration checks /wp-content/themes/{slug}/style.css the same way, since a theme's style sheet header conventionally carries its declared version.

User enumeration checks two separate leaks: the /wp-json/wp/v2/users REST endpoint, and the classic /?author=N redirect probe, which reveals a valid username through the URL a numeric author ID redirects to. Both hand an attacker a list of real usernames to aim a credential-stuffing or brute-force attempt at, well before any password is involved.

Vexta also checks for an XML-RPC pingback amplifier: when the X-Pingback header is present, that is flagged as a finding, since WordPress's pingback mechanism has a history of being abused to bounce requests off a site toward a third target, or to enumerate internal ports through the pingback request's own error responses.

What does the Drupal and Joomla deep scan check?

For Drupal, module enumeration probes /modules/contrib/{slug}/{slug}.info.yml, along with the older Drupal 7 module layout for sites still running it. Vexta also runs a dedicated Drupalgeddon-2 fingerprint, flagging an exposed /user/register endpoint on core versions in the range vulnerable to CVE-2018-7600, the remote code execution bug that made Drupalgeddon-2 one of the most widely exploited CMS vulnerabilities of its year.

For Joomla, extension enumeration probes /administrator/components/{slug}/{slug}.xml along with module manifest files, applying the same version-fingerprint-then-match approach used for WordPress plugins and Drupal modules.

How detected versions become findings

Every plugin, theme, module or extension version Vexta identifies is checked against an embedded vulnerability database keyed by CMS, slug, version range and CVE ID. A version that falls inside a vulnerable range becomes a finding tagged with that CVE, its severity, and remediation guidance, rather than a bare version number a hunter then has to look up manually.

Those findings carry through Vexta's proof-of-exploitation step and Confidence Score the same as findings from any other part of a scan, so a matched CVE on an obscure plugin nobody uses does not get equal weight with one on a component confirmed to be present and reachable. That distinction saves triage time on sites running a long tail of rarely used plugins, where a raw version match alone would otherwise produce a long list with no sense of which entries are worth a second look first.

Where CMS scanning fits in a full engagement

Plugin and module enumeration on their own are a starting point, not a finished assessment. They tell a hunter or a security team exactly what is installed and which of it is known-vulnerable, which is the fastest way to prioritize where a manual VAPT engagement should spend its time on a CMS-based site. Availability of the full CMS deep scan set depends on the license; see plans on the pricing page.