Security Check Report looks at 61 aspects of a WordPress installation and turns the findings into a graded report. It changes no setting, no file and no account. It stores its own results in the database, and it writes one temporary file in the uploads folder that is deleted again in the same request.

The report opens with the five things worth doing first, not with a table of 61 rows. Every finding says what was found, why it matters and what to do about it.

From the second run onwards the page no longer opens on the start button but on an overview: the grade, a line saying where the site stood on the first run and where it stands today, one bar per recorded run, five tasks to work through, what is still open, and what has been resolved and when.

Each task has a button that runs that one check again and answers within seconds, so a fix is confirmed while you are still on the screen instead of at the next full pass. A single re-check writes no point into the history, and the page says as much, because a grade pieced together from several passes is not a grade measured in one.

What you get

A weighted grade from A to F, where one failing critical check cannot be hidden by fifty passing minor ones
A checklist of five tasks at a time, derived from urgency and score rather than from guesswork, with the next one moving up when you finish one
A button per task that re-runs that single check, so you see the result of a fix in seconds
A history of the last 24 runs, with the very first one kept for good, so the starting point stays visible
A comparison with the previous run: newly failing, resolved, changed
Muting that remembers what a finding said, so an accepted finding comes back the moment it actually changes
“Not determined” as a real outcome, so a blocked request is never reported as a problem and never moves the grade
A count on the menu entry, a widget on the dashboard home and a reminder once the last run is more than 30 days old
Exports as plain text, JSON and CSV
A WP-CLI command that produces the same grade as the screen
An explanation of every check, searchable, right on the page

What it checks

Core, plugins and themes. WordPress version, PHP version against the published end-of-life dates, automatic core updates, core file integrity against the official checksums, files in the core directories that are not part of WordPress, pending plugin and theme updates, unused plugins and themes, plugins that look abandoned, plugins whose listing was closed, plugins whose author changed, must-use plugins and drop-ins, other WordPress installations sitting next to this one.

Configuration. Debug mode, debug log exposure, the theme and plugin editor, installing code from the dashboard, authentication keys and salts, table prefix, database user privileges, whether the scheduler actually runs, autoloaded options size, injected content in the options table, backups, login protection, password policy.

Files and permissions. Permissions on wp-config.php, the uploads folder and the core directories, world-writable paths, executable files among the media, whether the server runs PHP from the uploads folder, configuration and backup files that the server hands out, readable .git, .svn and .hg folders, database dumps in the web root, leftovers from interrupted updates, directory listing.

Accounts and access. Guessable passwords, predictable administrator names, how many accounts hold administrator rights and which have gone dormant, roles below administrator holding capabilities they should not have, open registration and the role it hands out, two-factor coverage per administrator, the application password inventory including when each was last used and from where.

Network and transport. HTTPS and the redirect from http, TLS certificate expiry and negotiated protocol, the security headers and their quality rather than their mere presence, cookie attributes, CORS, exposed software versions, legacy discovery tags, XML-RPC, user enumeration, REST routes that accept writes without checking permissions, and whether the client address can be faked through forwarded headers.

Transparency and disclosure. Whether AI-generated content carries a machine-readable label and whether visitors are told when they are talking to an AI system, which Article 50 of the EU AI Act has asked for since 2 August 2026. The disclosure plugins in the directory are recognised by their folder and by the settings they write, so a plugin that was installed and never set up is not mistaken for an answer. A site that publishes no AI output has nothing to label, so this one only ever warns and barely moves the grade.

What it is not

Not a firewall. It blocks nothing and intercepts no requests.
Not a malware scanner. It compares core files against the official checksums and looks for injected content in the options table, but it does not hunt for signatures in plugin or theme code, and it removes nothing.
Not a vulnerability database. It reports that a plugin is outdated, abandoned or delisted; it does not look up individual CVEs.
Not an auto-fixer. Every finding comes with instructions, and you carry them out.
Not a monitor. Nothing runs in the background, nothing is scheduled, no mail is sent. A check runs when you start it.

Data and connections

The plugin talks to api.wordpress.org and to your own site. Nothing else, and there is no telemetry. See the questions below for exactly which endpoints and what is stored locally.

Who builds it

CMS ADMINS maintains, hosts and secures WordPress and Drupal sites from Munich. This plugin is the checklist we run ourselves, packaged up. It is free, it stays free, and it works the same whether or not you ever talk to us.

CMS ADMINS Security Check Report

What you get

What it checks

What it is not

Data and connections

Who builds it