The fix, in one snippet
wp theme list
wp theme delete twentytwentytwoIllustrative 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 theme slugs from wp-content/themes/<slug>/ paths in the page HTML: the enqueued stylesheet, theme scripts, fonts and images. A child theme and its parent both load assets, so both usually appear. For each slug it requests /wp-content/themes/<slug>/style.css and reads the Version: line from the header comment that WordPress requires at the top of every theme stylesheet (the block that also carries Theme Name, Author and, for child themes, Template). Themes rarely register REST routes, so the route-signature method that drives plugin discovery seldom contributes here; the HTML path method is the main source, which also means inactive themes that never print assets are not seen from outside. The approach mirrors WPProbe (Valentin Lobstein / Chocapikk, MIT licence). Only files the theme already serves to every visitor are requested. Rated informational; the slug and version feed wordpress-vulnerable-theme.
Why it matters
A theme is PHP that runs on every page load with full application privileges, so it deserves the same scrutiny as a plugin, and it is often looked after less well. Commercial themes from marketplaces do not update through wordpress.org; they need a licence key and the vendor's own updater, and both tend to lapse after the site is built. Many bundle third-party components (sliders, page builders, form libraries) as copies inside the theme directory, which the component's own updater cannot reach. The 2014 Slider Revolution file-disclosure flaw (CVE-2014-9734) was exploited for years mainly through copies bundled in premium themes whose owners had no idea it was there. Inactive themes are a smaller version of the same problem: their files stay on disk and any directly reachable PHP remains callable. The WordPress scanning guide covers what an outside observer sees of your theme and how that maps to risk.
How to fix it
Keep the theme you use, one default theme as a fallback, and nothing else:
wp theme list
wp theme delete <slug>
wp theme update --all
wp theme auto-updates enable --allFor a marketplace theme, confirm the licence and the vendor's updater are active, and check whether it bundles components you also run as standalone plugins; if so, use the standalone plugin (which updates) and disable the bundled copy. Do not try to block style.css to hide the version: WordPress needs the header to recognise the theme and most themes enqueue the file for the browser, so blocking it breaks the site. The version header on a current theme is harmless; the goal is to make sure it is current. If you customise a theme, do it in a child theme so the parent can still be updated without losing your changes.
Where this fits
Installed themes identified is check 7 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 Installed plugins identified (info), where installed plugins were identified from the REST API route index and from asset paths in the page, with versions read from each plugin's readme.txt. 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
Installed themes identified closes one route in. Immediately below it: REST API route index publicly readable, where the REST API index at /wp-json/ lists every registered namespace and route to anonymous visitors; WordPress core version identified, where the exact WordPress core version could be read from the page or from readme.html; 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: Installed themes identified (info severity)
Scanner check id: wordpress-theme-inventoryThe 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.
