Plugin version with known vulnerabilities

Each plugin and version from wordpress-plugin-inventory is compared against Scan.now's vulnerability database: a processed copy of the Wordfence Intelligence feed (Defiant, Inc.) as redistributed by the WPProbe project (Valentin Lobstein / Chocapikk, MIT licence), holding more than 43,000 records across plugins, themes and core. Every record has an affected version range, severity, CVE identifier, CVSS score and vector, and an access requirement. A plugin is reported vulnerable when its version falls inside any record's range. The finding lists the matching CVEs sorted by CVSS, each tagged Unauth, Auth or Privileged, with the fixed version where the range has an upper bound; a range with no upper bound means no fix is recorded. Plugins whose version could not be read are listed in the inventory but are not matched, so nothing is claimed without a version. Identifications that rest on an ambiguous route match are marked as such. Scan.now never sends an exploit or a probe for the flaw; the result is a version comparison, so a site patched by a host without bumping the Stable tag can show a false positive. Rated high.

Exploitation of plugin vulnerabilities is automated and indiscriminate. When the File Manager plugin shipped an unauthenticated file-upload flaw (CVE-2020-25213), Wordfence documented attacks against hundreds of thousands of sites within days, and that pattern repeats with each significant disclosure: proof-of-concept code appears, scanners across the internet add it, and every site still on the affected version is tried. The access tag is the key to urgency. An Unauth entry with a CVSS score of 9 or more is a "patch today" item because no account is needed. Auth entries require a login, which matters less than it sounds on a site with open registration, a WooCommerce customer role, or a shared editor password. Privileged entries need an administrator and are typically chained after some other foothold. Abandoned plugins are the awkward case: a range with no fixed version means the author never patched, and the plugin may have been closed on wordpress.org without anyone telling you. The CVE and CVSS guide explains the scoring; how to read a scan report covers false positives.

Update the plugin to the fixed version shown in the finding, or everything at once:

wp plugin update <slug>
wp plugin update --all
wp plugin auto-updates enable --all

If no fixed version exists, remove the plugin rather than leaving it deactivated, since its files remain reachable either way:

wp plugin deactivate <slug>
wp plugin delete <slug>

Check the plugin's page on wordpress.org for a closure notice before keeping it. A premium plugin updates only while its licence is active. A firewall rule from your host or security plugin can cover the gap for a few days but is not a substitute for the patch. If any listed entry was unauthenticated, assume it may have been used and look for the usual traces: new administrator accounts, PHP files in wp-content/uploads/, modified core files, and unknown cron events:

wp user list --role=administrator
wp core verify-checksums
wp plugin verify-checksums --all
find wp-content/uploads -name '*.php'

Re-run the WordPress scanner after updating to confirm the version no longer matches any record.