The fix, in one snippet
wp plugin list --status=inactive
wp plugin delete <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
Scan.now discovers plugins two ways. The stealthy way sends GET /wp-json/ (and /?rest_route=/ when pretty permalinks are off) and matches the keys of the JSON routes object against a database of known plugin route signatures. A match on any of a plugin's routes identifies it, with a confidence percentage equal to matched routes divided by known routes; plugins that register identical route sets are marked ambiguous so you can confirm which one you run. The second way reads slugs out of wp-content/plugins/<slug>/ and wp-content/uploads/<slug>/ paths in the HTML. Versions come from /wp-content/plugins/<slug>/readme.txt, from its Stable tag: or Version: line. The dedicated WordPress scanner adds a light brute-force pass that requests readme.txt for the most popular plugin slugs not already found, after first requesting a random slug so a host that answers 200 to everything is not misread, the same calibration WPProbe performs. Every request is a plain GET for a file the plugin ships; no attack payloads are ever sent. Rated informational; the versions feed wordpress-vulnerable-plugin.
Why it matters
A plugin list is the first thing an attacker builds, because plugins are where WordPress gets compromised. The annual disclosure reports published by Wordfence and Patchstack attribute the large majority of WordPress vulnerabilities to plugins rather than core, and a plugin runs with exactly the same privileges as core: one arbitrary-file-upload bug in a gallery plugin is remote code execution on your server. The REST index makes the inventory nearly free. Any plugin that registers routes announces its namespace (contact-form-7/v1, wc/v3, elementor/v1) to anonymous visitors, whether or not it has any public-facing feature. Deactivated plugins matter too: their files are still served, so readme.txt still reports a version and any directly callable PHP file is still reachable. The value of seeing your own inventory is that it is usually longer than you remember, and every entry is code you are responsible for updating. The WordPress scanning guide covers plugin hygiene in detail.
How to fix it
Start with the list and remove what you do not use; deactivating is not enough because the files stay on disk:
wp plugin list
wp plugin delete <slug>
wp plugin update --all
wp plugin auto-updates enable --allThen make fingerprinting less convenient. Blocking readme.txt removes the version source (updating still matters more than hiding). nginx:
location ~* ^/wp-content/plugins/.+/readme\.txt$ { return 404; }Apache (in the site's .htaccess):
<FilesMatch "^readme\.txt$">
Require all denied
</FilesMatch>The route-index half of the fingerprint is addressed under wordpress-rest-routes-exposed. Neither measure hides a plugin that prints its own assets into the page, so treat them as friction, not protection, and rely on the inventory being current.
Where this fits
Installed plugins identified is check 6 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 WordPress core version has known vulnerabilities (high), where the WordPress core version on this site falls inside the affected range of at least one published vulnerability. 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 plugins identified closes one route in. Immediately below it: 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; 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.
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 plugins identified (info severity)
Scanner check id: wordpress-plugin-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.
