Check any WordPress site from the outside in about ten seconds: the WordPress version against the latest release, the PHP version against the current support table, outdated plugins and theme, exposed files such as debug.log and .env, open directory listings, user name leaks, XML-RPC, HTTPS and security headers. You get a grade from A+ to F, a plain verdict and a fix for each finding.
Runs on our server. The lookups are sent from srvscripts.com, so the result shows what one server in one location sees. Results are cached for 60 minutes per site; a share link keeps a copy for 30 days. Our server is not allowed to test itself, so srvscripts.com shows as "not tested".
Table of Contents
What the WordPress security check looks at
Each check has a weight; together they add up to 126 points. The score is the share of the weight that could be tested. Items we cannot test, for example a path your robots.txt asks crawlers to skip or a hidden PHP version, are shown as not checked and left out of the grade instead of counting for or against you.
| Check | Weight | What fails it |
|---|---|---|
| Sensitive files | 20 | A readable .env, .git/HEAD, wp-config.php.bak or wp-content/debug.log |
| WordPress version | 15 | A missing maintenance release on your branch, or two or more branches behind (one branch behind is a warning). A hidden version is estimated from public core files: all matches older than the latest = warning, latest only = passed, mixed = not counted |
| Plugins | 12 | Versions read from public files that are behind WordPress.org (three or more is a fail); up to 20 plugins are listed |
| PHP version | 10 | A reported version that predates the 21 October 2026 fixes, or an end-of-life branch (a hidden or unclear version is not checked) |
| HTTPS certificate | 10 | An untrusted or expired certificate |
| Installer | 10 | /wp-admin/install.php showing the setup form |
| Security headers | 8 | A security headers score under 80 (a warning, never critical on its own) |
| User name exposure | 8 | Login names listed by /wp-json/wp/v2/users or the ?author=1 redirect |
| Directory listing | 8 | An “Index of” page for /wp-content/uploads/ or /wp-content/plugins/ |
| HTTP to HTTPS redirect | 5 | http:// that does not redirect to https:// |
| XML-RPC | 5 | xmlrpc.php enabled (a warning; Jetpack and some apps still need it) |
| Theme | 4 | An installed theme behind its WordPress.org release |
| Mixed content | 4 | Scripts, styles or frames loaded over http:// on an https:// page |
| Backup and old-site folders | 4 | A reachable /backup/ or /old/ copy of the site |
| Version disclosure | 3 | The generator tag, the RSS feed version or /readme.html |
A readable secret file or an open installer is enough to lose a site, so either one caps the headline grade at F, however well the other checks do.
The REST API and the login page are reported for information only. WordPress needs the REST API, and a public login page is normal; what protects it is strong passwords, two-factor login and a limit on failed attempts.
Is the scan safe to run?
It is designed to have low impact. The scan is a set of unauthenticated, read-only HTTP checks: at most 30 small GET requests to the site (usually 21 to 26), plus lookups to api.wordpress.org for the latest versions. It never logs in, submits a form, sends a POST to xmlrpc.php or tries a password. File contents are only matched against a known pattern, then discarded; we never show or store them.
It does request well-known sensitive paths such as /.env and /wp-content/debug.log, the same way automated scanners do, so those requests can appear in your logs or trigger a firewall rule. No outside check can promise zero impact on a server.
Paths your robots.txt disallows are skipped. Requests identify themselves as srvScripts-WPCheck/1.0 (+https://srvscripts.com/tools/wordpress-security-check/), time out after 8 seconds and the whole scan stops at 40 seconds. We keep only the host name, the score, the time and which checks failed. Please scan sites you own or manage, or have permission to check.
WordPress Security Check at a glance
How to use this tool
- Enter the site address, for example
example.com. Without a scheme,https://is assumed. If the site redirects to another domain, the result tells you to test that address instead. - Press Scan WordPress site. A scan takes 5 to 15 seconds.
- Start with the Critical group, then the Warnings. Each row says what we found and why it matters, and the box under the results lists the fixes.
- After fixing, scan again. Results are cached for 60 minutes per site, so a re-scan within the hour shows the old result unless you wait. Purge your page cache or CDN after changes.
You can run 5 scans an hour (Pro members 50). Share the result with the share link, save it as PDF or download it as JSON from the result toolbar.
How to read the results
The grade is the share of the tested weight that passed: A+ from 97, A from 90, B from 80, C from 65, D from 50, otherwise F. A warning counts half. A readable secret file or an open installer caps the grade at F. Untested items are left out of the score, so the result shows a Coverage line next to it, for example 116 of 126 weighted points tested (92%), with the checks that were not tested. Read the two together. If less than 75% of the weight could be tested, the result says Not graded rather than guessing. A good grade describes what is visible from outside; it is not proof that a site is secure.
- Not a WordPress site: no
/wp-content/paths, generator tag or WordPress REST API were found, so the WordPress checks did not run. Use the website health check instead. - Estimated WordPress version: when a site hides its version, we compare up to 3 public core files (such as
wp-includes/css/dist/block-library/style.min.css) with the official WordPress.org checksums and show the releases that match, clearly labelled as an estimate. The actual version stays hidden. Several releases can share the same files, so you may see a range such as 7.1.1, 7.1.2. Grading of an estimate: every matching release older than the latest → warning (never critical); only the latest release → passed; a mix of the latest and older releases, or files that disagree, were changed or are unknown → not checked and not counted. - Firewall or bot challenge: a web application firewall answered instead of the site. That is usually good news, and we do not try to get past it.
- Not disclosed: a hidden WordPress or PHP version is not a problem. We cannot compare it, so it is not counted.
- Plugin versions are evidence, not proof: WordPress reads a plugin’s real version from its main PHP file, which visitors cannot see. We use the Stable tag in the plugin’s public
readme.txt(labelled likely) or, failing that, the?ver=on its files (labelled less reliable). Confirm in Dashboard → Plugins before acting.
PHP and the October 2026 security fixes
On 21 October 2026 the PHP project released PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 to fix two flaws it rates critical: CVE-2026-109618 (remote code execution via out-of-memory corruption) and CVE-2026-109619 (remote code execution via stale global state). The php.net announcements list the same versions.
The check reads only the PHP version the site itself reports in its X-Powered-By or Server header and compares it with those releases. It never guesses PHP from WordPress, jQuery, plugin or theme versions, and it does not test for either flaw.
| Result | When | Effect on the grade |
|---|---|---|
| Potentially affected | The reported version predates the fix for its branch (for example 8.3.35), or it is PHP 7.4, 8.0 or 8.1, which have no supported upstream release (the PHP project published source backports only) | Critical. A warning when the version carries a vendor suffix such as -1~deb12u5, because the vendor may have backported the fixes |
| Version indicates fixed | 8.2.35, 8.3.36, 8.4.27, 8.5.12 or a later patch on the same branch | Passed. The branch’s support stage is shown separately and not graded: 8.2 and 8.3 get security fixes only, which still includes these fixes |
| Not determined | The version is hidden, unreadable, incomplete (8.3), conflicting, a pre-release (8.4.27RC1) or on a branch the advisories do not cover | Not checked: no points either way |
End of life is judged separately from these two flaws. PHP 8.1 and older are end of life, so they are marked critical whatever their patch level. For PHP 7.4, 8.0 and 8.1 the result says: “No supported upstream release is available for this branch. Confirm a vendor-patched build or an applicable source backport, and plan migration to a supported branch.” The PHP project published source backports for those branches, which are not maintained releases. PHP 8.2 reaches end of life on 31 December 2026. A version-based finding never triggers the automatic F used for readable secret files or an open installer.
Vendor builds such as CloudLinux alt-php, distribution packages and TuxCare ELS can contain backported fixes under an older version number, which no outside check can see. Server-side verification must check the PHP runtime actually serving this website, its installed package and vendor patch information. CLI php -v can refer to a different installation. After updating, restart or reload the relevant PHP workers as required by the vendor.
The JSON download carries the same assessment under php: the detected version and its source, assessment (potentially_affected, version_indicates_fixed or unknown), the CVE IDs, the fixed version for the branch, branch support and the vendor-backport caveat.
Fix the most common findings
- debug.log is public. Delete
wp-content/debug.log, setWP_DEBUG_LOGto a path outsidepublic_htmlor turn it off, and block*.login the web server. If the log contained passwords or keys, change them. - Directory listing is on. Add
Options -Indexesto.htaccesson Apache or LiteSpeed, orautoindex off;on nginx. - User names are exposed. Block
/wp-json/wp/v2/usersfor visitors who are not logged in and stop the?author=redirect; most security plugins have a switch for both. Use a login name that differs from the display name and turn on two-factor login. - XML-RPC is enabled. Keep it if Jetpack, the WordPress mobile app or another client needs it. Otherwise disable it with a security plugin, or block it in
.htaccesson Apache or LiteSpeed with the three lines shown below this list. - WordPress or plugins are outdated. Take a backup, update in Dashboard → Updates, and remove plugins you no longer use. If an update breaks the site, our hacked WordPress cleanup guide covers restoring from a clean copy.
- PHP predates the October 2026 fixes or is end of life. Update to PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later, move to a supported branch, or ask your host to confirm that both fixes are backported into the build serving your site. Follow how to update PHP on cPanel, DirectAdmin and CloudLinux, and keep the version hidden with
expose_php = Off.
To block XML-RPC in .htaccess, add these lines exactly as shown, each on its own line, then reload the site and run the scan again to check the result:
<Files "xmlrpc.php">
Require all denied
</Files>Would you rather not touch the server yourself? The Get it fixed box under a result sends the issues to our fixed-price service; you get the price first and nothing changes without your OK.
What this check cannot see
This is a version and public-exposure checker, not a vulnerability scanner: it does not match your plugins or theme against a vulnerability database, so a plugin that is up to date but has an unfixed flaw will not be flagged.
An outside scan sees what any visitor sees. It cannot find malware hidden in files or the database, weak or reused passwords, plugins that load nothing on the home page, server settings, backups or file permissions. A good grade means the public surface looks right, not that the site is clean. For a site that may already be hacked, follow the cleanup guide or ask us for a hacked site cleanup.
Lab test, 22 Oct 2026: on our WordPress 7.1.1 lab site with planted problems (outdated Contact Form 7 and WP Statistics, a public debug.log, an open uploads listing, readme.html, XML-RPC on and the author redirect), the scan reported every planted problem and graded the site F, in 22 requests and about 6 seconds. A planted .env file and /backup/ folder were correctly not flagged, because the web server already refused them with HTTP 403.
Also try
- Website Health Check: SSL, redirects, headers and SEO basics for any site.
- Security Headers Checker: the exact header lines to add, with a score out of 100.
- SSL Certificate Checker: chain, expiry and host name match.
- Email Deliverability Test: check that your WordPress contact form and order mail reach the inbox.
Frequently asked questions
Is this WordPress security scan free?
Yes. It is free with 5 scans an hour per visitor and no sign-up. Pro members get 50 scans an hour.
How much load does the scan put on my site?
Very little; it is designed to have low impact. It sends at most 30 small GET requests, respects robots.txt, never logs in or sends POST requests, and stops after 40 seconds. It does request known sensitive paths, so the requests may appear in your logs or trip a firewall rule.
How do you find the plugin versions?
From the plugin paths in the home page HTML, then each plugin’s public readme.txt (Stable tag), and the ?ver= on its files as a fallback. WordPress itself reads the version from the plugin’s main PHP file, which is not public, so treat these as strong hints and confirm in Dashboard → Plugins. Premium plugins that are not on WordPress.org are listed but not compared.
Why is my PHP version marked as not checked?
Most servers hide the PHP version. When the headers do not report a full, stable PHP version, we cannot tell which version serves the site or whether it has the October 2026 fixes, so the PHP check is marked not checked and left out of the grade. An unknown version is not a sign that it is supported or patched. Check it in Tools → Site Health → Info → Server.
Does a good grade mean my site is secure?
No. The scan only sees the public surface and does not use a vulnerability database. Malware in files or the database, weak passwords and server settings are invisible from outside. Treat the grade as a quick exposure check, not an audit.
Does “version indicates fixed” mean my server is safe from CVE-2026-109618 and CVE-2026-109619?
No. It means the PHP version your site reports is at or above the release that contains both fixes. It is not an exploit test, and a vendor build can differ from upstream. Check the PHP package that actually serves the site and your vendor’s advisory.
Why are some checks marked as not checked?
Your robots.txt asks crawlers to skip that path, the request limit or time limit was reached, or a firewall blocked the request. Those checks are left out of the grade rather than counted as passed or failed, and the Coverage line under the score shows how much of the weight was tested.