Fingerprint the install
The REST route index (/wp-json/ and ?rest_route=/) is matched against 5,300+ plugin route signatures, and slugs are pulled from wp-content paths in the HTML.
Scan a WordPress Site for Vulnerable Plugins, Themes and Core
Enter a WordPress site. Scan.now reads its REST route index, page markup and readme files to identify the plugins, theme and core version, then matches every version against a Wordfence-derived database of 43,000+ known vulnerabilities. No payloads, no login attempts.
Public hosts only. About a handful of requests, usually finished in under 15 seconds. How we scan · Acceptable use
46,358 vulnerability records and 5,344 plugin route signatures loaded, refreshed 2 h ago. Data from Wordfence Intelligence, © Defiant, Inc.
Scanning…
First results
The full scan is still running
How it works
Read the versions
Each plugin's readme.txt gives its Stable tag; the theme's style.css gives its version; core comes from the generator tag, asset URLs or readme.html.
Match known CVEs
Every version is checked against the vulnerability database. Findings list each CVE with its CVSS score, whether exploitation needs a login, and the version that fixes it.
How a passive WordPress vulnerability scan works
The scanner inventories public WordPress fingerprints and compares detected versions with known vulnerability ranges without attempting exploitation.
WordPress risk usually comes from the combination of core, a theme and many independently maintained plugins. Identifying a plugin name is not enough: the installed version must fall inside a vulnerable range before a version-specific advisory can be treated as applicable.
Scan.now reads the public REST route index, WordPress asset paths, generator metadata and accessible readme or stylesheet files. Route signatures can identify a plugin even when its name is not printed in the page. Version evidence is then compared with the locally maintained advisory database and reported with CVE, severity, authentication requirements and the fixed version when available.
Identify WordPressRead public markup, REST routes and conventional asset paths.
Inventory componentsCombine plugin, theme and core fingerprints with version evidence.
Match advisoriesCompare exact versions with affected ranges and prioritise the result.
Put this result in context
This scanner answers one part of the review. Continue with Website Scanner for headers, tls, cookies, exposed files, then LLM API Key Scanner for openai, anthropic, gemini and other ai keys. These are separate checks because a strong result here does not prove that the adjacent surface is healthy.
For the background behind these signals, read Scanning a WordPress Site for Vulnerabilities: What Attackers Look For First and Exposed Files: .git, .env, Backups and Debug Pages That Leak Your Site's Secrets. The Scan.now methodology explains request limits, scan boundaries and what the scanner deliberately does not attempt.
WordPress detection and vulnerability evidence
Confidence depends on the public evidence available for each component.
| Evidence | What it can reveal | Important interpretation |
|---|---|---|
| REST route signatures | Installed plugins that register distinctive public API routes. | Shared frameworks can create ambiguous matches, which the report labels rather than guessing. |
| Asset paths | Plugin or theme slugs visible in CSS, JavaScript, image and font URLs. | A slug identifies a component but does not always reveal its version. |
| Readme and stylesheet metadata | Stable plugin version and theme name or version when files are publicly readable. | Blocked files produce an unknown version, not a clean vulnerability result. |
| Core fingerprints | Generator metadata, asset version strings and conventional WordPress files. | Caching or removed metadata can hide or preserve an old-looking version. |
| Advisory range match | CVE, CVSS score, affected versions, authentication requirement and fixed release. | Only evidence-backed version matches should drive version-specific remediation. |
How to read a WordPress scan
Separate detected software, known vulnerable versions and unknown versions.
No matched advisory
No detected version fell inside a known affected range. Continue updating because the database and installed software change.
Vulnerable version matched
The public version evidence intersects a known advisory range. Update to the fixed release or remove the component.
Version unknown
The component appears installed but no reliable version was exposed. Confirm it from the WordPress dashboard or deployment inventory.
Reduce WordPress attack surface
- Back up and update vulnerable core, themes and plugins to supported fixed releases.
- Remove disabled or abandoned components because inactive code can still remain publicly reachable.
- Confirm ambiguous and unknown-version detections inside the authorised administration panel.
- Retest after updates and monitor the advisory database for newly disclosed affected ranges.
What this result does not prove
- A passive scan cannot inventory components that expose no supported public fingerprint.
- Version strings can be hidden, cached or modified, so unknown and low-confidence results require owner verification.
- The scan does not log in, brute-force users, install code or send exploit payloads.
Related tools
Continue the review with four checks that cover adjacent parts of the same attack surface.
Website Vulnerability Scanner
Headers, TLS, cookies, exposed files
LLM API Key Exposure Scanner
OpenAI, Anthropic, Gemini and other AI keys
SSL / TLS Checker
Certificate, expiry, protocols, ciphers
Security Headers Checker
CSP, HSTS, frame and MIME policies
Guides for this tool
Background reading written to go with these results.
9 min read · Updated Sep 15, 2026
Scanning a WordPress Site for Vulnerabilities: What Attackers Look For First
WordPress runs a large share of the web and is attacked accordingly. What an external scan reveals about a WordPress site, from version...
Read the guide
9 min read · Updated Sep 12, 2026
Exposed Files: .git, .env, Backups and Debug Pages That Leak Your Site's Secrets
Many breaches start with a file that should never have been public: A .git folder, a .env with database credentials, a backup archive or...
Read the guide
9 min read · Updated Sep 16, 2026
CVE and CVSS Explained: How Vulnerabilities Are Named, Scored and Prioritised
Every public vulnerability gets a CVE identifier and usually a CVSS score. How the numbering works, what the score measures and does...
Read the guide
9 min read · Updated Sep 18, 2026
How to Read a Security Scan Report: Severity, False Positives and What to Fix First
A scan report is a list of findings with severities, and the hard part is deciding what matters. How severities are assigned, how to...
Read the guide
8 min read · Updated Sep 20, 2026
Outdated JavaScript Libraries: Why Old jQuery and Angular Are a Real Risk and How to Find Them
A page that ships an old library ships its known vulnerabilities. How Retire.js-style detection works, the most common vulnerable...
Read the guide
13 min read · Updated Sep 13, 2026
Website Security: What a Vulnerability Scan Looks For and How to Fix It
A website vulnerability scan checks the parts of a site an attacker can reach without logging in: Transport security, HTTP headers,...
Read the guideFrequently asked questions
How are plugins detected without logging in?
WordPress publishes a REST route index at /wp-json/ that every installed plugin adds its own routes to. Matching those routes against a database of known plugin signatures identifies what is installed, a technique the open-source WPProbe project developed. Slugs in wp-content paths and readme.txt files fill in the rest.
Where does the vulnerability data come from?
A processed copy of the Wordfence Intelligence feed, redistributed by the WPProbe project and refreshed daily. It covers plugins, themes and core, with an affected version range, CVE, CVSS score and whether exploitation needs authentication for each record.
A plugin is listed but I do not have it installed. Why?
Some plugins register identical REST routes, usually because they are forks or share a framework. Those are marked ambiguous in the report with the alternatives listed. A low confidence percentage means only a few of the plugin's known routes matched.
My plugin version is not shown.
Version detection reads readme.txt from the plugin directory. Hosts that block direct file access, or plugins that ship no readme, leave the version unknown, so we cannot say whether it is vulnerable. That is reported as unknown rather than guessed.
Is this the same as WPScan?
The goal is similar; the method is passive only. Scan.now never attempts logins, never enumerates users by brute force and never sends exploit payloads. It reads public files and the public REST index.
How current is the vulnerability database?
It is refreshed by a daily job on the server. The report footer shows the age of the data used for that scan.
