Title: BadgerScan
Author: cyberbadger
Published: <strong>August 22, 2026</strong>
Last modified: August 22, 2026

---

Search plugins

![](https://s.w.org/plugins/geopattern-icon/badgerscan.svg)

# BadgerScan

 By [cyberbadger](https://profiles.wordpress.org/cyberbadger/)

[Download](https://downloads.wordpress.org/plugin/badgerscan.0.5.27.zip)

 * [Details](https://ido.wordpress.org/plugins/badgerscan/#description)
 * [Reviews](https://ido.wordpress.org/plugins/badgerscan/#reviews)
 *  [Installation](https://ido.wordpress.org/plugins/badgerscan/#installation)
 * [Development](https://ido.wordpress.org/plugins/badgerscan/#developers)

 [Support](https://wordpress.org/support/plugin/badgerscan/)

## Description

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.

### External services / Privacy

BadgerScan relies on the BadgerScan service operated by CyberBadger (https://badgerscan.
cyberbadger.ca) to score your scan and, if you connect an account, to store your
history and send reports.

 * **What is sent:** your site URL, the plugin version, the WordPress core/plugin/
   theme versions and counts, the configuration and exposure flags listed above,
   and the file names of any suspicious or modified files we flag. If you have connected
   an account, your connect key.
 * **What is never sent:** post or page content, usernames in bulk, passwords, or
   other personal data.
 * **When:** when you run a scan. That means a manual click, or the automatic daily
   scan once you have consented by running your first scan. Never on install, and
   never before you consent. You can switch this off on the BadgerScan screen at
   any time; that stops the daily scan and the polling below.
 * **Polling (connected accounts only):** if you have connected an account, the 
   plugin also asks the service every 15 minutes whether you have requested a re-
   scan from your dashboard. That request sends your site address, the plugin version,
   and your connect key, and nothing else. It runs a scan only if you asked for 
   one, and it stops entirely if you switch automatic contact off.
 * **Why:** to calculate your grade and, for Pro, to save history and send alerts.

Terms: https://badgerscan.cyberbadger.ca/terms
 Privacy: https://badgerscan.cyberbadger.
ca/privacy

## Installation

 1. In your WordPress dashboard, go to Plugins, then Add New, then Upload Plugin, and
    choose the BadgerScan .zip file. (Or copy the `badgerscan` folder into `wp-content/
    plugins/` over SFTP.)
 2. Activate BadgerScan from the Plugins screen.
 3. Open the BadgerScan item in your wp-admin menu and click Run security scan. Your
    grade and findings appear in a minute or two. No account is required.
 4. Optional: create an account at https://badgerscan.cyberbadger.ca/account, copy 
    your connect key, and paste it into the BadgerScan screen to add the combined outside-
    plus-inside grade, scan history, alerts, and the specific CVEs for your versions.

## FAQ

### Does it change anything on my site?

No. Every check is read-only. It reads WordPress state and reports on it; it never
edits your files, your settings, or your content. Like any plugin it does store 
its own settings (your consent flag, your connect key) and caches its last result,
and it removes all of them when you delete it.

### Do I need an account?

No. Every check, the grade, and the automatic daily scan all work with no account.
An account adds what the service does for you: the combined outside-plus-inside 
grade, scan history, email alerts, and the specific CVEs.

### Why does the plugin’s code contain words like eval and base64_decode?

Because it looks for them. Part of the scan reads files in your uploads folder and
checks whether any of them contain the code patterns a PHP backdoor uses. Those 
patterns have to appear in our source as plain text so we can search for them. BadgerScan
never calls any of them: it has no eval, no base64_decode, and no shell access anywhere.
They are kept readable, in one clearly labelled list, rather than disguised to slip
past a scanner.

### What data leaves my site?

Only read-only findings (versions, counts, and flags) plus your site URL, sent to
the BadgerScan service to compute your grade. Never your content, usernames, or 
passwords. See the External services section above.

### How do I connect my account?

Create a free account at https://badgerscan.cyberbadger.ca/account, copy your connect
key, and paste it into the BadgerScan screen in wp-admin.

## Reviews

There are no reviews for this plugin.

## Contributors & Developers

“BadgerScan” is open source software. The following people have contributed to this
plugin.

Contributors

 *   [ cyberbadger ](https://profiles.wordpress.org/cyberbadger/)

[Translate “BadgerScan” into your language.](https://translate.wordpress.org/projects/wp-plugins/badgerscan)

### Interested in development?

[Browse the code](https://plugins.trac.wordpress.org/browser/badgerscan/), check
out the [SVN repository](https://plugins.svn.wordpress.org/badgerscan/), or subscribe
to the [development log](https://plugins.trac.wordpress.org/log/badgerscan/) by 
[RSS](https://plugins.trac.wordpress.org/log/badgerscan/?limit=100&mode=stop_on_copy&format=rss).

## Changelog

#### 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.

## Meta

 *  Version **0.5.27**
 *  Last updated **1 day ago**
 *  Active installations **Fewer than 10**
 *  WordPress version ** 5.8 or higher **
 *  Tested up to **7.0.4**
 *  PHP version ** 7.4 or higher **
 *  Language
 * [English (US)](https://wordpress.org/plugins/badgerscan/)
 * Tags
 * [hardening](https://ido.wordpress.org/plugins/tags/hardening/)[malware](https://ido.wordpress.org/plugins/tags/malware/)
   [scanner](https://ido.wordpress.org/plugins/tags/scanner/)[security](https://ido.wordpress.org/plugins/tags/security/)
   [vulnerability](https://ido.wordpress.org/plugins/tags/vulnerability/)
 *  [Advanced View](https://ido.wordpress.org/plugins/badgerscan/advanced/)

## Ratings

No reviews have been submitted yet.

[Your review](https://wordpress.org/support/plugin/badgerscan/reviews/#new-post)

[See all reviews](https://wordpress.org/support/plugin/badgerscan/reviews/)

## Contributors

 *   [ cyberbadger ](https://profiles.wordpress.org/cyberbadger/)

## Support

Got something to say? Need help?

 [View support forum](https://wordpress.org/support/plugin/badgerscan/)