Methodology & scope

This page covers everything worth knowing before you buy: exactly what we check, how we verify it, and what we deliberately don't check.

What we do, technically

• We send a handful of standard GET requests to your homepage, /readme.html, /wp-json/, and /wp-login.php.
• We read the PHP version from the X-Powered-By header when the host exposes it (most hosts hide this now; if it's missing, PHP checks are simply skipped).
• We read the WordPress core version from the generator meta tag or readme.html.
• We read each plugin's version from the ?ver=X.Y.Z string WordPress appends to its public CSS/JS files.
• Every detected version is matched against the verified signature list below using a simple version comparison.

How we verify every signature

A CVE isn't marked "active" until three things are confirmed:

• We read the original advisory (the CVE record plus the plugin's or PHP's own changelog) and confirm the CVSS score.
• We confirm the exact affected version range.
• We confirm the exact version the fix shipped in.

Until all three are done, the entry stays marked verified: false in the code and the scanning engine never matches against it — on purpose, to avoid false positives or negatives.

What we actively check for right now

What we deliberately don't check

• No exploitation, brute force, or login attempts — every check is purely passive.
• No authenticated-area scanning — we only check pages anyone can already see.
• No malware, backdoor, or file-integrity scanning.
• No live SQL injection, XSS, or other exploit attempts — only version fingerprinting.
• No server/hosting misconfiguration or WAF auditing.
• Nothing outside the verified list above — including zero-days — will ever be detected.

This is not a replacement for a full penetration test — it's a fast way to catch known, high-impact issues. For more on how the scanning bot itself behaves, see about our scanner.