CMS ADMINS Security Check Report

Changelog

Releases before 2.2.0 are listed in changelog.txt.

2.4.0

Added

• A checklist instead of a one-off verdict. From the second run onwards the page opens on an overview: the grade, where the site started and where it stands today, a bar for every run, the five things to work through, what is still open, and what has been resolved and when. The guided three-step walkthrough stays for the first run.
• Every task carries a button that re-runs that one check and answers within seconds. A fix is confirmed while you are still at the screen, and the next task moves up, instead of waiting for the next full pass.
• A history of the last 24 runs. The very first one is kept for good, so the opening line can always name where the site started. An installation upgrading from an earlier version finds its two stored runs as the first two points.
• Progress per category, so it is visible which part of the site has been dealt with and which has not.
• A sixth area, transparency and disclosure, with one check in it: whether AI-generated content on the site is labelled. Article 50 of the EU AI Act has asked for a machine-readable label and a notice for AI chatbots since 2 August 2026. The disclosure plugins from the directory are recognised by their folder and by the settings they write, and the check only ever warns, because a site with no AI content has nothing to label.
• A count on the menu entry, a widget on the dashboard, and a reminder once the last full run is older than thirty days. The reminder can be switched off for good, per user.

Changed

• The report is built on the server now. It used to be assembled in the browser, which meant the overview could not exist before a run had finished, and the same markup would have had to be written twice.
• A single re-check never writes a point into the history, and the page says plainly that the grade then rests partly on older measurements. A partial pass is not a run.
• A run stores what each check reported, so the report can be rebuilt without running everything again.

Fixed

Every check was read against the sources it cites: php.net, the WordPress handbook, core source, MDN, and the packages of the plugins it recognises. That turned up findings that fire on correct configurations, one that could not fire at all, and claims that stopped being true years ago.

• Sites with two-factor protection were reported as having none. The user meta key stored for iThemes, Solid and Kadence Security is not the one those plugins write, and the one for Defender does not exist in it at all. Google Authenticator stores the string “disabled”, which counted as a second factor because it is not empty, so the one case the check exists for went unnoticed.
• The check for plugins removed from the directory could not fire. The API answers 404 for a closed listing, and the WordPress function turns that into an error before the “closed” flag is ever read, so the check reported all clear in exactly the case it was written for. It now asks the endpoint itself and tells a closed listing, a plugin that was never listed and an unreachable one apart.
• WordPress installed in its own directory was reported as an injected option value, at critical severity. Comparing the site and home addresses cannot tell that apart from a takeover, and in a real takeover both are changed together, so the comparison is gone.
• A site behind Cloudflare was reported as having a spoofable client address. The check now looks for a proxy that identifies itself and says the result is undetermined when it cannot tell, rather than warning.
• The WooCommerce Store API was reported as a write route left unprotected. Registering a route as public is the spelling the handbook prescribes, so a route with no permission callback at all and one that is deliberately public are now told apart.
• The strict Content Security Policy from the published guidance was reported as leaving the hole it closes. Browsers that understand ‘strict-dynamic’ ignore the ‘unsafe-inline’ fallback beside it, and the check now does the same. A host wildcard is no longer mistaken for allowing scripts from anywhere.
• DISALLOW_FILE_MODS closes the file editor and stops background updates. Neither check knew that, so following this plugin’s own advice left one finding standing and turned another into a false all clear.
• system.multicall has not amplified password guessing since WordPress 4.4, and the XML-RPC check now recognises the filter most security plugins use to switch the interface off.
• The advice to pick a display name different from the login name does nothing, because the author slug keeps the login name it was generated from.
• Application passwords were reported as switched off on every site without HTTPS, which is where WordPress refuses them in the first place.
• A server that hands out the source of a PHP file was reported as running it. Those are different problems with different fixes.
• .user.ini and .htpasswd were listed among files to delete. They are live configuration, and deleting the second one locks people out.
• On IIS the check for .htaccess advised saving the permalink settings, which writes web.config there and never an .htaccess.
• A role that merely appeared since the first run, as a shop or membership plugin does, was reported as a role holding administrator-level power.
• Installers and shell scripts among the uploads are no longer treated as code the server runs.
• A run stored by 2.3.2 could raise a PHP warning on the first page view after the update, and the mute state it was saved with is now kept until a run of this version replaces it.
• Scans and lookups that cannot complete now say so instead of reporting all clear: a core file scan that hit its limit, a plugin listing that could not be retrieved, a database dump whose URL did not answer.

Explanations

• Every one of the sixty-one entries was read against the method it documents. Fourteen described outcomes the check does not have, or stayed silent about the ones it does.
• The entry on security headers now names the values to enter, which is the one thing it was missing. The permission entries say where to change file permissions without shell access. Roughly a dozen terms are resolved where they first appear rather than assumed.
• The warning about the table prefix named the wrong mechanism, and the reasoning for 640 against 440 on wp-config.php was inverted. Files in the web root were called harmless as a group, although phpinfo.php prints the whole PHP environment.

2.3.2

Fixed

• The check for executable files in the uploads directory reported the empty index.php that WordPress and most plugins drop into every upload folder to stop directory listing. Those files are the opposite of a finding, and because the check counts as critical, a single one of them pulled an otherwise healthy site down to grade D. Across twenty sites the grade was identical for that reason alone. The check now reads such a file instead of judging it by name: an index.php passes only when it stays small and reads no request data, includes no other file, calls none of the functions a dropped shell needs and prints nothing of its own. Everything else is still reported, index.php included.
• Every reported file now carries its size and, where an index.php did not pass, the reason it was reported. A guard file runs to a few hundred bytes, so the number alone usually settles what a file is.
• Two-factor coverage could not tell an account that never finished the setup from one it simply could not read, and called both inconclusive. Each supported plugin is now listed together with the user meta it writes, so an installed plugin nobody uses is reported as the exposure it is, naming the accounts without a second factor.
• Two-factor detection now covers ReportedIP Hive, Solid Security, Kadence Security, WP Defender and Google Authenticator. iThemes Security has been renamed twice and ships under three folder names, all of which are recognised.

2.3.1

• The screen is now laid out as three steps: start the check, read the result, go through everything else. Steps two and three say what they will contain before the first run, so the page explains itself.
• The start button says what it does and how long it takes, and the note about the temporary file sits directly above it.
• The result opens with a plain sentence, not just a letter: how many findings need attention now, how many are worth improving, and how many checks could not be completed.
• The page scrolls to the result when a run finishes, instead of leaving it below the fold.
• The priority list is now called what it is, a to-do list, and says to work through it in order.
• A finding can carry a link to further help. The two-factor finding uses it to point at the Two Factor plugin from the WordPress core team and at ReportedIP Hive, which we build ourselves and name as ours.
• Removed three interface strings and two stylesheet rules left behind by the rebuild.

2.3.0

Rebuilt

• One registry is now the single source of truth for a check: identifier, label, grouping, urgency, weight, callback and documentation used to live in four separate places that nothing kept in sync. A test now enforces that they match.
• Grading moved out of the browser and into PHP, which makes the result reproducible, testable and available outside the dashboard.
• The admin-ajax endpoint was replaced by REST routes under cascr/v1, running three checks at a time instead of strictly one after another.
• Results are stored, so the report can compare a run with the one before it.

Added

• Twenty-five checks, among them publicly readable configuration files and repository folders, database dumps in the web root, must-use plugins and drop-ins, role and capability changes, the application password inventory with last use, two-factor coverage per administrator, unauthenticated REST write routes, TLS certificate expiry, HSTS and CSP quality, cookie attributes, client address spoofing and plugin ownership changes.
• wp security-check run as a WP-CLI command.
• A priority list of the five things worth doing first, at the top of the report.
• A comparison with the previous run: newly failing, resolved, changed.
• Muting with a content fingerprint, so an accepted finding reappears as soon as it actually changes.
• “Not determined” as its own outcome, so a blocked request is no longer a finding and no longer affects the grade.
• Exports as plain text, JSON and CSV.
• The filters cascr_registry and cascr_test_result.

Fixed

• Multisite reported “registration is closed” on a network that let anyone sign up, because the check read the per-site option that multisite ignores. It now reads the network setting.
• Network administrators were missing from the password, administrator, two-factor and application password checks. They hold every capability regardless of their role on a site, so a role query alone did not find them.
• The table prefix check compared the per-site prefix on multisite, so every subsite looked like it had a custom one.
• A stored cross-site scripting path: findings carrying site data such as plugin names or user names were written into the summary with innerHTML.
• Permission checks compared against exactly 0755 and therefore reported 0750 and the widespread setgid 2755 as insecure.
• WP_AUTO_UPDATE_CORE set to true was reported as a risk, although it enables more updates than the recommended setting.
• “Not modified in six months” was treated as “outdated”, which flagged well maintained plugins. Replaced by release date, tested-up-to version and directory status.
• The malware signature scan searched wp-admin and wp-includes for strings such as eval( and $_GET[, and needed a hand-maintained list of 180 core files to stay quiet. Replaced by a comparison against the official WordPress file list.
• Security headers were all or nothing. They are now scored per header, with the cross-origin isolation headers treated as optional.
• The interface followed the operating system colour scheme and painted dark cards onto the light dashboard. It now follows the WordPress admin.

Changed

• One request to the homepage per run instead of four, and one update lookup instead of one request per installed plugin.
• Duplicate checks merged (PHP version support, XML-RPC methods, login attempt limiting) and two dropped that could never fail (jQuery version, table storage engine).
• Every string in the interface is translatable. The report was previously hardcoded English with a German date format.
• Counts in the report use proper plural forms instead of assuming plural.
• The JavaScript alert was replaced by an admin notice and a screen reader announcement.
• The test suite now runs against multisite as well, as a blocking step before every release.

2.2.2

• Broadened PHP compatibility: the plugin runs on PHP 7.4 through 8.5
• Requires WordPress 7.0 or newer
• Added an automated test suite covering every check and the permission and nonce gates
• Continuous integration lints on seven PHP versions and runs the tests against WordPress 7.0 and the current release
• Fixed a PHP warning in the theme and plugin update checks when a path no longer exists
• Removed unused legacy code paths and reached full WordPress Coding Standards compliance

2.2.1

• First release on the WordPress.org plugin directory
• Renamed plugin folder, main file and text domain to security-check-report
• Removed the Spamhaus IP blacklist test, which sent the server address to a third party without asking
• Removed unused legacy code and files
• Fixed translation loading on WordPress 6.7 and newer
• Enabled certificate verification for the PHP execution test request

2.2.0

• Redesigned interface with a native details and summary accordion
• Added a live search across the check documentation
• Rewrote every check description into a consistent format: what it checks, why it matters, what to do
• Unified the colour scheme and fixed several layout issues