WordPress core version has known vulnerabilities

The version identified by wordpress-core-version is compared against records of type "core" in Scan.now's vulnerability database. That database is a processed copy of the Wordfence Intelligence vulnerability feed published by Defiant, Inc., as redistributed by the WPProbe project (Valentin Lobstein / Chocapikk, MIT licence). It holds more than 43,000 records covering plugins, themes and core; each record carries an affected version range, a severity, a CVE identifier, a CVSS score and vector, and whether exploitation requires authentication. A finding is raised when the running version falls inside any core record's range. The report lists the matching CVEs sorted by CVSS score, tags each with its access requirement (Unauth, Auth or Privileged), and shows the fixed version where the range has an upper bound. Scan.now never attempts to exploit anything; the result is a version comparison. Rated high by default. If the version was read only from a stale readme.html on a site that was patched by other means, the finding can be a false positive, which is why all three version sources are shown.

Core vulnerabilities are rarer than plugin ones but universal: an exploit for the WordPress 4.7.0 and 4.7.1 REST API content-injection flaw (CVE-2017-1001000) worked against every site on those versions, and defacement campaigns began within days of disclosure. Automatic background updates for minor releases have existed since WordPress 3.7 precisely to close that window, so a site showing a vulnerable core version usually means the mechanism has been disabled or broken. The Unauth, Auth and Privileged tags in the report are the triage key. An unauthenticated flaw with a high CVSS score is an emergency: anyone on the internet can use it. An authenticated one needs an account, which on a site with open registration or weak passwords is not much of a barrier. A privileged one requires an administrator or editor, which usually means it is a stepping stone rather than an entry point. The CVE and CVSS guide explains how to read the scores and vectors, and how to read a scan report gives a triage order.

Update core, run the database upgrade, and confirm the core files match the release checksums:

wp core update
wp core update-db
wp core verify-checksums

Then make sure it cannot fall behind again. In wp-config.php, check that automatic updates have not been switched off, and enable them:

define('WP_AUTO_UPDATE_CORE', true);
// remove or set to false if present:
// define('AUTOMATIC_UPDATER_DISABLED', true);

If the dashboard reports that updates are unavailable, the web server user cannot write to the WordPress directory, or DISALLOW_FILE_MODS is set; fix the permissions or update by deploying from your pipeline. On managed hosting where the host controls the version, ask them to move you to the current release. If any listed CVE was unauthenticated, check for signs it was used before you patched: unexpected administrator accounts, recently modified PHP files under wp-content/uploads/, and unfamiliar scheduled events:

wp user list --role=administrator
wp cron event list
find wp-content/uploads -name '*.php'

Re-run the WordPress scanner to confirm the version no longer matches.