by
Patrick Schlesinger
5 (2 reviews)
CMS ADMINS Security Check Report
Read-only security audit for WordPress: 62 checks including PHP2Shell, an A to F grade, and a checklist that records what you have fixed.
CMS ADMINS Security Check Report ranks #9,364 among WordPress.org plugins with 400+ active installations, is #592 of 5,058 in the Security category, a 5/5 rating from 2 reviews, and was last updated Oct 23, 2026. Data from WordPress.org, refreshed twice daily — see methodology.
Compatible with WP 7.1.4
v2.5.0
Current Version v2.5.0
Updated 2 weeks ago
Last Update on 23 Oct, 2026
Refreshed 1 week ago
Last Refreshed on
#592 of 5,058 in Security
Top 25% by installs
Downloads -80.6% this week
Actively maintained
Rank
#9,364
—
No change
Active Installs
400+
+110.5%
KW Avg Position
63.6
0.6 better
Downloads
1.9K
+2 today
Support Resolved
0%
—
No change
Rating
100%
Review 5 out of 5
5
(2 reviews)
Next Milestone 500
400+
500+
280
Ranks to Climb
-
Growth Needed
8,000,000
Active Installs
Pro
Unlock Exact Install Count
See the precise estimated active installs for this plugin, calculated from real-time ranking data.
- Exact install estimates within tiers
- Track install growth over time
- Milestone progress predictions
Need 19 more installs to reach 500+
Rank Changes
Current
#9,364
Change
Best
#
Downloads Growth
Downloads
Growth
Peak
Upgrade to Pro
Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.
Upgrade NowReviews & Ratings
5.0
2 reviews
Overall
100%
5
2
(100%)
4
0
(0%)
3
0
(0%)
2
0
(0%)
1
0
(0%)
Security History
Source: WPVulnerabilityNo known vulnerabilities on record for CMS ADMINS Security Check Report. Checked 1 month ago.
Track This Plugin
Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.
Start Tracking FreePlugin Details
- Version
- 2.5.0
- Last Updated
- Oct 23, 2026
- Requires WP
- 7.0+
- Tested Up To
- 7.1.4
- PHP Version
- 7.4 or higher
- Author
- Patrick Schlesinger
Support & Rating
- Rating
- ★ ★ ★ ★ ★ 5
- Reviews
- 2
- Support Threads
- 0
- Resolved
- 0%
Keywords
Upgrade to Pro
Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.
Upgrade NowSimilar Plugins
Adminify – White Label, Admin Menu Editor, Login Customizer
6K+ installs
#2,757
Master Addons for Elementor – Elementor Addons, Widgets, Mega Menu Builder, Popup Builder, Widget Builder & Template Kits
30K+ installs
#1,015
LiteSpeed Cache
7M+ installs
#5
Akismet Anti-spam: Spam Protection
5M+ installs
#8
Wordfence Security – Firewall, Malware Scan, and Login Security
5M+ installs
#11
Really Simple Security – Simple and Performant Security (formerly Really Simple SSL)
3M+ installs
#18
Hostinger Tools
3M+ installs
#20
WPS Hide Login
2M+ installs
#27
Limit Login Attempts Security - Login Security, 2FA, Firewall, Brute Force Prevention
1M+ installs
#33
WP Super Cache
1M+ installs
#36
TL;DR
AI summary of the plugin's readmeThis plugin is for WordPress site owners and admins who want a read-only security audit of their installation. It runs 60 checks across core files, configuration, file permissions, accounts, and network settings, then produces a graded report with a prioritized fix list.
- 60 security checks
- A to F grading
- Priority list of top fixes
- Comparison with previous run
- Muting for accepted findings
- "Not determined" outcome status
- Exports to TXT, JSON, CSV
- WP-CLI command support
Frequently Asked Questions
Common questions about CMS ADMINS Security Check Report
PHP2Shell is the name for two critical flaws in the PHP core, rated CVSS 9.2. A single request without a login can run code on the server, on PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed alike. The PHP team published the fixes on 21 October 2026: you need PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer. PHP 8.1 and older get no official release, only backports from some distributions and vendors. The PHP2Shell check reads the PHP version the site actually runs on and says one of two things: Green: the fix is proven. That is the case for PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or newer within each branch, for PHP 8.6 or newer, and for the Ubuntu package revisions that carry the backport. Orange: the fix cannot be proven from the version number. Red Hat, Plesk, cPanel and self-built packages often keep the old number after a backport, so an orange result means "update, or have your host confirm the backport", not "you have been hacked". The check never shows red, because a version number alone cannot prove that a server is vulnerable. After an update, restart PHP-FPM or the web server and run the check again. Fixed versions and the status per distribution: PHP2Shell: critical PHP flaws CVE-2026-109618/109619 (German).
No. Every check reads state and reports on it. There is one exception, and it is deliberate. To find out whether your server would execute a PHP file dropped into the uploads folder, the plugin has to try. It writes one file with a random name, requests it once over HTTP and deletes it in the same request. A shutdown handler removes the file even if PHP dies in between, and anything left behind by an earlier interrupted run is cleaned up before the next one starts.
Only to api.wordpress.org, to the same endpoints WordPress itself uses for its update checks: https://api.wordpress.org/core/version-check/1.7/, read from the update information WordPress already holds, to learn the current WordPress version. The plugin never asks this endpoint itself. https://api.wordpress.org/plugins/update-check/1.1/ and https://api.wordpress.org/themes/update-check/1.1/ for pending updates, likewise read from what WordPress already holds https://api.wordpress.org/plugins/info/1.2/ to see whether a plugin listing is still open and when it was last released. This is the one endpoint the plugin requests directly rather than through plugins_api(), because a closed listing is served as an HTTP 404 that plugins_api() turns into an error, which loses the very flag the check needs. The answer is cached for twelve hours. https://api.wordpress.org/core/checksums/1.0/ for the official core file hashes WordPress.org privacy policy and terms of service. The remaining requests go to your own site, because several checks can only be answered from the outside: whether a file is served, whether a header is sent, whether a directory is listed. There is no telemetry and no reporting back to the plugin author. One of those requests to your own site does not use the WordPress HTTP API. The certificate check opens a plain TLS connection to your own host name on port 443 to read the expiry date, because the HTTP API does not hand the certificate back. The target is still your own site and nothing leaves it, but WP_HTTP_BLOCK_EXTERNAL and the pre_http_request and http_request_args filters do not apply to that one connection.
A handful of options in your database, all removed when you delete the plugin: the last run and the one before it, so the report can show what changed the history of the last 24 runs, each one holding the date, the grade, the risk score and a single character per check, which is what the progress display reads
a baseline recorded on the first run, holding plugin authors, role definitions and the list of must-use plugins and drop-ins, so later runs can spot changes the number of failing checks from the last run, so the count on the menu entry does not have to load a whole run on every admin page the moment you agreed to the run, so you are not asked again on every visit Two entries go into user meta. One is a login timestamp per account, because WordPress keeps no login history of its own and the administrator check would otherwise have nothing to say about dormant accounts. The other records that somebody switched off the reminder notice, which is a decision per person rather than per site. Both are deleted on uninstall.
Neither. It finds configuration weaknesses and exposure, which is what most WordPress sites are actually taken over through. It does not block traffic and it does not clean an infected site. It will notice several things that point at a compromise: core files that differ from the official release, executable files in the uploads folder, must-use plugins or drop-ins that appeared out of nowhere, roles that gained administrator capabilities, injected scripts in the options table. If any of those turn up, treat it as a starting point for an investigation, not as a verdict.
A, excellent: nothing of substance outstanding B, good: minor improvements available C, moderate: several things worth addressing D, poor: significant weaknesses, act soon F, critical: act now
Every check carries an urgency, and the urgency sets how much a finding weighs: Critical, weight 3.0: authentication, code execution, exposed secrets High, weight 2.0: updates, transport security, important configuration Medium, weight 1.5: headers, permissions, policies Low, weight 1.0: fingerprinting and good practice The score is the weighted risk as a percentage of the worst possible outcome. Checks that could not be determined are left out of both sides of that calculation, so a blocked outbound request never moves the grade in either direction. A failing critical check pulls the result down to at least a D, which is what stops one serious problem from being averaged away. A few checks are informational and carry no weight at all.
Because it could not get an answer, usually a blocked outbound request or a file it is not allowed to read. That is deliberately not treated as a finding. An unreachable endpoint says nothing about your site, and reporting it as a problem would teach you to ignore the report.
Mute it. The plugin hides the finding and stores a fingerprint of what it was reporting. As soon as the content changes, for instance one more affected file, it comes back on its own. That is the difference between accepting a known state and going blind to it, and it is why muting is offered instead of a permanent dismissal by default.
