The fix, in one snippet
wp theme update <slug>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
Each theme slug and version from wordpress-theme-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). The database holds more than 43,000 records across plugins, themes and core; each carries an affected version range, severity, CVE identifier, CVSS score and vector, and whether exploitation needs authentication. The theme is reported vulnerable when its version falls inside any theme record's range. The finding lists the matching CVEs sorted by CVSS with their Unauth, Auth or Privileged tag and the fixed version where the range has an upper bound. A theme whose style.css header carries no version is listed in the inventory but not matched. Nothing is exploited or probed; this is a version comparison, and a vendor that patched without changing the header produces a false positive. Rated high.
Why it matters
Theme vulnerabilities are exploited exactly like plugin ones, and the worst of them are as bad as anything in the ecosystem. The Bricks builder theme's unauthenticated remote code execution flaw (CVE-2024-25600) was under active attack within days of the February 2024 disclosure. Page-builder themes are the usual source because they accept rich input, render user-controlled templates and ship large amounts of PHP. Two things make theme findings harder to close than plugin ones. First, the update path: a theme bought from a marketplace updates only when its licence is valid and the vendor's updater is installed, so a site can sit on a vulnerable version indefinitely while the dashboard shows nothing. Second, the parent-child split: a customised parent theme cannot be updated without losing the changes, which is why owners postpone the update and why the child-theme pattern exists. Read the access tag before deciding urgency, as explained in the CVE and CVSS guide.
How to fix it
Update to the fixed version shown in the finding:
wp theme update <slug>
wp theme update --all
wp theme auto-updates enable --allIf the theme came from a marketplace and the update does not appear, install the vendor's updater plugin or upload the new version by hand from your account, then verify with wp theme list. If your customisations live in the parent theme, move them into a child theme now so the parent can be replaced:
/* wp-content/themes/<slug>-child/style.css */
/*
Theme Name: My Site Child
Template: <slug>
Version: 1.0.0
*/If no fixed version exists and the vendor is unresponsive, switch themes; a deactivated theme's files are still reachable, so delete it once the switch is done. If any listed entry was unauthenticated, check for compromise before assuming the update closed the matter: wp user list --role=administrator, unexpected PHP under wp-content/uploads/, and wp core verify-checksums. Re-run the WordPress scanner to confirm.
Where this fits
Theme version with known vulnerabilities is check 4 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 Plugin version with known vulnerabilities (high), where at least one installed plugin is at a version with published vulnerabilities. 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
Theme version with known vulnerabilities closes one route in. Immediately below it: WordPress core version has known vulnerabilities, where the WordPress core version on this site falls inside the affected range of at least one published vulnerability; Installed plugins identified, 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; Installed themes identified, where the active theme (and its parent, if it is a child theme) was identified from asset paths in the page, with the version read from the theme's style.css header.
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: Theme version with known vulnerabilities (high severity)
Scanner check id: wordpress-vulnerable-themeThe 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.
