Your WordPress, Drupal, or Joomla version is public, and bots check it first

A vulnerable JavaScript library runs in the visitor's browser. A vulnerable CMS is worse, because the CMS runs on your server. When WordPress, Drupal, or Joomla has a known hole and you haven't patched it, the exploit doesn't target a visitor. It targets the machine that hosts everything, and a successful one means a stranger is running code on your server, not theirs.

The part that makes this a passive finding, something readable from outside without attacking anything, is that these platforms broadcast their own version. You don't have to break in to learn what's running. The site tells you, in the page source, on purpose.

How the version announces itself

CMS platforms leave version markers in places that are trivial to read.

WordPress writes a <meta name="generator" content="WordPress 5.8"> tag into the page head by default, and ships a /readme.html that states the version outright. Drupal exposes its version in a generator meta tag and historically in /CHANGELOG.txt. Joomla announces itself in a generator tag too. None of this requires a login or a probe; it's in the HTML and the standard files the platform serves. A scanner reads the marker, parses the version, and compares it to the maintained-release floor. Below that floor means the platform is either end-of-life or missing security patches, and for a CMS that's a high-severity finding, because the exploits are public.

Why bots check this before anything else

A content management system is a giant, popular, well-documented target. When a CVE lands for a specific WordPress, Drupal, or Joomla version, the proof-of-concept exploit usually lands with it, and within hours there are bots crawling the whole internet looking for sites running the affected version.

They don't fingerprint cleverly. They read the generator tag or hit /readme.html, match the version against their list of known-vulnerable releases, and if it's a hit, they fire the exploit. The famous Drupal cases, "Drupalgeddon" and its sequels, worked exactly this way: a critical flaw, a public exploit, and mass automated scanning that compromised unpatched sites at scale within days. Drupal 7, 8, and 9 are now end-of-life and get no security fixes, so any site still on them is permanently behind the patch line. This is the server-side sibling of fingerprinting your stack from the headers: same idea, higher stakes, because the thing being fingerprinted is the application running your whole site.

Patch, and quiet the version while you're at it

The real fix is to stay current: run a supported major version and apply security updates promptly. CMS security releases are almost always for actively-exploited flaws, so "I'll update next month" is a real window of exposure.

# WordPress 5.4, three majors behind, auto-updates off
# generator meta and /readme.html announce the version
# no schedule for security patches

Enable automatic security updates where the platform supports it (WordPress does for minor releases), and put major upgrades on a real schedule instead of "when something breaks." Removing the generator tag and deleting /readme.html makes you a quieter target by not advertising the version, but treat that as a delay, not a defense: the fix is being on a version with no open holes, not hiding which version you're on. If you're on an end-of-life branch like Drupal 7, the only safe move is migrating to a supported one.

What version of WordPress, Drupal, or Joomla you're running is something the platform publishes in the page and its standard files, so a stranger reads it without touching anything they shouldn't, and so do we. SurfaceCheckr reads the generator marker or the shipped version file, and flags an install that's at or below the maintained-release floor, with the version it found. We only flag when there's both a real CMS marker and a parseable version, so we never guess. We read the version you advertise; we don't run the exploit or confirm the specific flaw is reachable on your install, because that's active and we stay passive. The version is the finding. Closing the window between a public CVE and your patch is the work, and it's a lot less work than rebuilding a compromised server.