The fix, in one snippet
define('WP_AUTO_UPDATE_CORE', true);Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now reads the core version from three places and reconciles them. The <meta name="generator" content="WordPress 6.6.2"> tag is the most direct. /readme.html, shipped with every release, prints the version near the top of the page. Finally, core enqueues its own scripts and styles with a ?ver= query string equal to the running version, so a URL such as /wp-includes/js/jquery/jquery.min.js?ver=6.6.2 reveals it even when the generator tag has been removed; only /wp-includes/ assets are considered, because plugins append their own versions to their own files. Where the sources disagree, the report shows all of them. The identified version is then compared against records of type "core" in the vulnerability data described under wordpress-vulnerable-core. This check is informational; the fact that the number is visible is rated separately under wordpress-version-disclosure.
Why it matters
The version number is mostly useful to you. It tells you which branch you are on, whether automatic minor updates are actually working, and whether you are within the range the WordPress security team still patches; the project ended security backports for the 4.1 to 4.6 branches in 2024, and a site still on one of them is running unfixable code. For an attacker the number is a convenience rather than a necessity: a core exploit is tried against every WordPress site in reach whether or not the version is advertised, and the fingerprint can be reconstructed from file hashes anyway. Hiding the version therefore buys little, while a version that is behind the current release is a real signal that updates have stalled, typically because a host froze them, file permissions broke the updater, or someone disabled automatic updates during a plugin conflict and never turned them back on. The WordPress scanning guide explains how to interpret the number alongside the plugin findings.
How to fix it
First make sure the version is current, which matters far more than whether it is visible:
wp core update
wp core update-db
wp core verify-checksumsThen reduce the disclosure. In a small must-use plugin or your child theme's functions.php:
remove_action('wp_head', 'wp_generator');
add_filter('the_generator', '__return_empty_string'); // also strips it from RSS/Atom feeds
add_filter('script_loader_src', 'scannow_strip_core_ver', 15);
add_filter('style_loader_src', 'scannow_strip_core_ver', 15);
function scannow_strip_core_ver($src) {
global $wp_version;
return (strpos($src, 'ver=' . $wp_version) !== false) ? remove_query_arg('ver', $src) : $src;
}Deleting readme.html works until the next core update restores it, so block it at the server instead. nginx:
location = /readme.html { return 404; }Apache:
<Files "readme.html">
Require all denied
</Files>Where this fits
WordPress core version identified is check 9 of 10 that the website vulnerability scanner runs under wordpress plugins, themes and core, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits REST API route index publicly readable (info), where the REST API index at /wp-json/ lists every registered namespace and route to anonymous visitors. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
WordPress core version identified closes one route in. The next one down is WordPress detected, where the site runs WordPress.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: WordPress core version identified (info severity)
Scanner check id: wordpress-core-versionThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
