Your WordPress is patched, but is the plugin with the public RCE? The plugins bots hunt by version

WordPress core is the safe part. The project ships security updates, most sites auto-update it, and an outdated core is a minority case. The danger has moved underneath, to the plugins. The average WordPress site runs a dozen or more, each is third-party code with full access to the site, and the popular ones accumulate critical vulnerabilities at a steady clip: unauthenticated privilege escalation, file-upload-to-RCE, object-injection RCE. A site can run a perfectly current WordPress core on top of a plugin with a public, weaponized exploit.

What makes this a passive, checkable thing, rather than guesswork, is that a plugin advertises its own version. Every plugin ships a readme.txt at a fixed path, with a Stable tag: line stating exactly which version is installed. That file is the same one WordPress.org and every update checker reads. So an attacker (and a scanner) can read the version off the plugin itself, match it against the known-vulnerable window, and know whether this specific install is exploitable, no guessing, no probing.

The plugins, the CVEs, the version floors

These nine are mass-exploited, each tied to a specific CVE and a specific version window. The pattern across them is grim: unauthenticated, meaning no login needed, leading to privilege escalation, account takeover, or remote code execution.

A CVSS 10.0 on GiveWP isn't a typo, it's the maximum score, meaning unauthenticated, network-reachable, and total compromise. These are the holes that turn a WordPress site into someone else's server within hours of the exploit going public.

How a bot finds a vulnerable one (and how the scanner does the same)

The attack is automated and tireless. A bot has a list of plugin slugs and their vulnerable version windows. For each site, it requests the plugin's readme.txt at its canonical path, reads the Stable tag:, and checks it against the window. If it's in range, the site goes on the exploit list. The whole thing is reconnaissance by public file read, the version is sitting there to be read, because WordPress's own update mechanism depends on it being readable.

The scanner reads the same file the same way, and it's deliberately strict about it. It only fires on a confirmed WordPress site, and only when the plugin's own readme is actually served at its canonical slug path, with the matching === Name === title, and a parseable Stable tag: that lands at or within the CVE window. If the readme isn't served, or the version can't be read, it says nothing, it never guesses a version it can't see. Every CVE and floor here is verified against NVD, WPScan, or a vendor advisory. So a finding means: this exact plugin, at this exact readable version, sits in a known-exploited window.

The fix, and why it's urgent

There's only one real fix for a vulnerable plugin: update it. The patched versions exist, the CVE windows above all close at a known release, and updating to the current version is the cure.

# the readme tells the world it's exploitable
litespeed-cache  Stable tag: 6.2.0.1   <- in the CVE window
give             Stable tag: 3.14.0     <- CVSS 10.0 RCE
# bots are checking this file right now

Update the flagged plugins immediately, an unauthenticated RCE with a public exploit is not something to schedule for next sprint. Then make it stick: enable plugin auto-updates so the next critical CVE gets patched before a bot finds you, delete plugins you don't use (every installed plugin is attack surface, even deactivated), and prefer plugins that are actively maintained, because an abandoned plugin's next CVE never gets a patch at all.

Reading it from outside

Whether one of your plugins is on a known-exploited version is something a stranger settles by reading a public readme, which is exactly what SurfaceCheckr does, a plain GET of the plugin's own readme.txt (or a theme's style.css), the same file every WordPress update checker reads. It only reports on a confirmed-WordPress site, only when the readme is genuinely served and carries a parseable version in the CVE window, and it never guesses a version it can't read. It reads the version the plugin volunteers and stops, no exploit, no payload, nothing active. This is the recon step an attacker's bot is already running against your site; the check simply runs it first, so you can patch before the version on that readme line becomes an entry on someone's exploit list. For the client-side cousin, outdated JavaScript libraries with public XSS, and the WordPress config files bots check alongside, round out the WordPress picture.