BadgerScan

Most WordPress security plugins look at your site from one side. A scanner on the outside sees your headers and certificate but has to guess at your versions. A plugin on the inside knows your exact versions but cannot see what your server actually serves to a visitor. BadgerScan looks from both sides and reconciles the two into a single grade. That reconciliation is the point, because the two views disagree more often than you would expect, and the disagreement is usually the interesting part:

• A weakness that is real inside but blocked at your web server stops dragging your grade down, instead of scaring you about something visitors cannot reach.
• A setting that looks correct inside but is not actually enforced where it counts is caught, instead of passing quietly.
• An outdated component the outside scan can only guess at is confirmed by the exact version read from inside.

It is strictly read-only about your site. It never edits one of your files, changes one of your settings, or touches your content, and it reports findings rather than content: versions, counts, and flags, never your posts, usernames, or passwords. The only things it writes are its own: your consent flag, your connect key, and its cached scan results. It checks:

• WordPress core, plugin, and theme versions and pending updates
• Admin accounts, the "admin" username, and open registration
• Configuration: WP_DEBUG, the dashboard file editor, XML-RPC, table prefix
• Exposure: backup files, debug logs, and readme.html sitting in the web root
• Transport: HTTPS

It is read-only and data-minimized. It reports versions, counts, and flags only. It never reads, stores, or transmits your post content, usernames in bulk, or passwords, and it never changes one of your settings, edits one of your files, or alters your content. It stores only its own options and cached results. Free vs Pro The scan and grade are free, with no account required. Connect a BadgerScan account to unlock Pro:

• The full report: the outside view of what your site shows the public internet (DNS, email, TLS, headers, exposed files, from public data only) combined with the inside view, as a branded PDF you can keep or hand to a client
• The specific CVE IDs and fixes for your exact plugin, theme, and core versions
• Email alerts the moment your grade drops or a new CVE hits a version you run
• Full scan history in your dashboard, so you can see the trend rather than one snapshot

BadgerScan Pro is C$10/mo per site. CyberBadger, who make BadgerScan, also do the fixing for people who would rather hand it over: a one-off analyst review with a remediation plan, or fully managed WordPress upkeep. Those are services, not plugin features, and nothing in the plugin depends on them.

0.5.28

• Corrected the sensitive-files finding. It said the outside scan checks whether those files can be downloaded, but the outside scan does not request them. The finding now says only what the plugin can see: the files exist in your web root. The severity is unchanged.

0.5.27

• Internal: restored a code-analysis annotation that was dropped in 0.5.23, so the bounded execution-time guard no longer shows up as an unexplained warning in WordPress's Plugin Check.

0.5.26

• The note on the connect form no longer promises a daily scan when you have switched automatic contact off.
• Tidied two internal comments that still described how the automatic-contact switch worked before 0.5.25, and one duplicated style rule.

0.5.25

• Switching automatic contact off now stays off. Previously, connecting or disconnecting an account afterwards re-recorded your consent and quietly restarted the 15-minute dashboard check, while the screen still showed it switched off.
• That switch now clearly governs both automatic behaviours, the daily scan and the dashboard re-scan check, rather than appearing to control only the daily scan.
• The on-screen notice now says that a scan also happens once a day without a click, unless you switch it off.
• Deleting the plugin from a multisite network now removes its scheduled jobs from every site, not just the one it was deleted from.

0.5.24

• Fixed: connecting or disconnecting an account switched the automatic daily scan off, because those forms share a handler with the scan form and did not carry the new daily-scan checkbox. Connecting an account no longer disables the automation it enables.
• On a multisite network, the daily scan is now scheduled on every site rather than only the one the plugin was activated from.
• Corrected the data list in this readme: the plugin no longer sends an email address, and it does send the plugin version and the names of any suspicious files it flags.
• Added an FAQ entry explaining why the plugin's own code contains words like eval and base64_decode (it searches for them; it never runs them).
• Stopped writing a cached scan result that nothing read back.

0.5.23

• You can now switch the automatic daily scan off from the BadgerScan screen. Before this, running one scan started a daily one with no way to stop it short of deactivating the plugin.
• The 15-minute check for re-scans you queue from your dashboard is now described in the plugin and in this readme. It was never hidden, but it was not written down either.
• Corrected the "read-only" wording. Every check is still read-only about your site and nothing about your files, settings, or content is ever changed, but the plugin does store its own settings and cached results, and saying it never writes to the database at all was too broad.
• Restored a WordPress file the previous release removed by mistake, which had silently stopped the core-integrity and auto-update checks from running on the automatic daily scan.
• Deleting the plugin now clears its data from every site in a multisite network, not just the current one.
• Scanning no longer forces a WordPress update check on every run, and no longer removes the PHP time limit outright.

0.5.22

• The sensitive-files finding now says those files are present in your web root, rather than claiming they are reachable from the web. From inside your site we can only see that the file exists; whether your server actually serves it is something only the outside scan can confirm. The severity is unchanged, because a credentials file sitting in the web root is a real risk whether or not a rule currently blocks it.
• Removed two unnecessary WordPress admin file loads.

0.5.21

• The admin page's styles are now tied to the screen identifier WordPress itself assigns, instead of one assumed in advance, so they cannot fail to load.

0.5.20

• Compatibility: the one place that still passed the autoload setting as a string now passes a boolean, matching every other option write in the plugin and the form newer WordPress versions expect.

0.5.19

• The automatic daily scan now runs for every site that has consented, not only sites with an account. It was built-in functionality gated behind connecting, which the WordPress.org guidelines do not allow, and there was no good reason for it: the scan result is useful on its own. Consent is still required, because the scan contacts an external service.
• The admin page's styles are now delivered through WordPress's own enqueue system instead of an inline style tag.
• The uploads folder is now located through WordPress rather than assumed to be wp-content/uploads, so the check behaves correctly on multisite and on installs with a custom uploads path.
• Removed leftover references to the closed beta.

0.5.18

• Hardening and code-quality pass ahead of the WordPress.org listing. The one user-visible effect is none: no check, grade, or finding changes.
• The status glyph beside each finding is now escaped on output like every other value we print, rather than emitted as a raw HTML entity.
• Moving the stored connect key off autoload no longer needs a direct database write, and no longer depends on a function only present in WordPress 6.4 and later.

0.5.17

• Fairer XML-RPC reporting: if Jetpack or VaultPress is active (including network-activated on multisite), XML-RPC being enabled is now reported as expected rather than as a weakness, since those plugins need it to work. The advice becomes how to contain the risk without breaking them, such as allowing only that plugin's IP ranges or rate-limiting logins. Sites without such a plugin still get the finding, now worded around what actually makes XML-RPC risky.
• readme.html is now reported as "present in your web root" rather than as a confirmed disclosure. Whether visitors can actually read it is your web server's decision, which only the full outside scan can see, so the plugin no longer claims an exposure it cannot observe. The advice leads with blocking it at the web server, since deleting the file needs file access that managed hosting often does not give you.

0.5.16

• New informational check: your report now notes how many of your active plugins are not set to auto-update (and calls it out if plugin auto-updates are turned off for the whole site). Auto-updates apply security fixes without waiting on a person. This is context only and never affects your grade, since leaving auto-updates off can be a deliberate choice. It reflects the effective setting, so a managed host that patches for you is not counted as missing.

0.5.15

• The core integrity check no longer raises a false "core files do not match" alarm while a WordPress update is installing. A core update briefly leaves your site a mix of two releases, which used to look like modified files for a scan run in that moment. The check now confirms each changed file against the official checksums for both your current version and the version being installed: if every change matches the incoming release it reports "core update in progress" and invites a re-scan, while a file that matches no official release still surfaces as a critical finding. The decision is based only on WordPress.org's official checksums, never on any local file, so it cannot be tricked into staying quiet.

0.5.14

• wp-admin now shows the right grade for your plan. With a connected Pro account, it shows the same combined inside and outside grade as your dashboard, because the outside scan now runs as part of the scan. Without one, it shows your inside grade, clearly labeled, and no longer over-reports A+ by skipping the hardening checks (HSTS, DMARC, two-factor) that only the full scan confirms.
• More accurate HTTPS check. The grade now follows your site's canonical address (Site and Home URL) rather than how you happen to be viewing wp-admin, so browsing the dashboard over https no longer hides a site that still serves visitors over plain HTTP.
• The HTTPS finding no longer tells you to install a certificate when it simply could not reach your site over https to check (for example when outbound requests are blocked from your server). It now separates three cases: you have a certificate and only need to enforce it, a certificate responded but is not valid (expired, self-signed, or for the wrong domain), and https could not be confirmed from here.
• Clearer account message: if your BadgerScan account is already at its site limit, connecting a new site now says so plainly instead of showing a generic "connect key was not recognized" error.
• The connect / account panel now stays visible if a scan can't reach the service, so a temporary error no longer hides your connection status.
• Widened login-protection detection (WP Cerber, Shield Security) so more hardened sites are recognized. Older entries have moved to changelog.txt, which ships with the plugin.