Guard Forge hardens your WordPress site against common attacks without an account or an API key. It applies hardening rules, watches for brute-force login attempts, protects accounts with two-factor authentication, compares your files with what wordpress.org actually published, and keeps an audit log that shows if anyone edited or deleted a line afterwards.

Login protection. Failed logins are counted per IP address; past the threshold the address is locked out and unblocked automatically later. Every logged-in user can switch on two-factor authentication for their own account: a time-based one-time code (TOTP), a login challenge and single-use recovery codes. The QR code for enrolment is drawn on your own server, so the secret never leaves the site.

File integrity. Once you switch the monitor on, every core file and every plugin hosted on wordpress.org is compared with the checksums wordpress.org publishes for that exact release. The screen separates files that are official, modified, missing, and not in the official build at all, which is what a backdoor looks like. Premium and custom plugins and all themes have no published checksums, so they are marked “no reference” and never counted as clean. The check asks wordpress.org with a version number and a plugin slug, and never sends your site address or anything about your content.

Audit log. Logins, failed attempts, option changes, plugin and theme activity and user and role changes are recorded, and every row carries the hash of the row before it. “Verify chain” walks the table: an edited row no longer matches its own hash, and a deleted row leaves the next one pointing at a hash nothing produces.

Hardening score. Twenty-one checks of your own installation add up to a score from 0 to 100. Each row states how many points it is worth and links to the screen that changes it. The score makes no outbound request.

Free

Hardening score: twenty-one checks, 0-100
Login brute-force protection with per-IP lockout and automatic unblock
Two-factor authentication (TOTP) with recovery codes for every logged-in user’s own account
File integrity against the official wordpress.org checksums (off until you switch it on)
Hash-chained audit log with chain verification
Hardening: disable XML-RPC, remove version headers, protect wp-config.php through .htaccess
Content-Security-Policy header, report-only by default
IP management: allowlist, lift a lockout, login-log browser
Spam-bot honeypot on the comment form
Core file protection rules (.htaccess)
Staging mode: on a copy of your site lockouts are recorded but not enforced, and no notification, alert or firewall rule leaves the copy

Pro add-on (separate plugin, not part of this download)

Two-factor enforcement for administrators
Alerts to Telegram, Slack and a signed webhook
Lockdown mode
Real-time vulnerability database
Patch by update (off until you switch it on)
Geo-IP blocking and Cloudflare firewall sync
Managed firewall ruleset (SQL injection, local file inclusion, XSS, PHP injection)
Malware scanner
AI threat analytics
Audit log export to CSV

The only request this plugin makes is the checksum lookup to wordpress.org, and only while the file-integrity monitor is switched on. See External services below.

Documentation: https://guardforge.app/docs/

External services

This plugin reaches wordpress.org, and nothing else. Activating it contacts nobody and schedules nothing that would — the file-integrity monitor is off on a fresh install, and switching it on is what puts the daily lookup on the schedule. The only outgoing request it ever makes is the checksum lookup below, it happens only while the file-integrity monitor is switched on, and it asks a public catalogue a question that names nothing of yours.

wordpress.org, for the file-integrity scan. Off until you switch the monitor on in GuardForge > Settings. Then once a day, and whenever you press “Run scan now”, GuardForge asks api.wordpress.org for the checksum list of your WordPress version and locale, and downloads.wordpress.org for the checksum list of each installed plugin it hosts (its folder name and version number). Those are public catalogues: the request carries the version, the locale and the slug, and nothing else — not your site’s address, not your user list, not your content, not a licence key. Answers are cached, and one scan makes at most ten requests, so a site with sixty plugins is covered over a few days rather than in one burst. Switch the file-integrity monitor off in Settings and none of this happens.

Endpoints: https://api.wordpress.org/core/checksums/1.0/ · https://downloads.wordpress.org/plugin-checksums/
WordPress.org privacy policy: https://wordpress.org/about/privacy/ (wordpress.org publishes no separate terms page for this lookup)

Nothing about your site is sent on a schedule or in the background. A fresh install makes no request at all and schedules none; with the file-integrity monitor switched on it has one daily request — the checksum lookup, while that monitor is on — and it asks a public catalogue a question that names nothing of yours. Switch the file-integrity monitor off and this plugin makes no outgoing request at all.

Uninstalling

Deleting GuardForge always removes one thing: your two-factor enrolments. That table holds TOTP shared secrets and single-use recovery codes — credential material — and once the plugin is gone nothing can use them, while a database that outlives the plugin gets backed up, exported and copied to staging. Reinstalling means enrolling again, which takes half a minute; leaving shared secrets behind has no upside at all.

Everything else stays by default: your login log, file-integrity snapshots, audit trail and settings all survive a delete, so removing the plugin by accident does not take your history with it. If you want a clean slate, tick Delete GuardForge data on uninstall in GuardForge Settings before you delete.

When the last Forge plugin or add-on on a site is deleted, everything Forge stored on the site is removed, on every site of a network: the statistics settings and the install ID, the shared job queue with its scheduled events, and the other settings and caches the Forge plugins share. While another Forge product stays, only this plugin’s own share goes. The paragraphs above are about this plugin’s own content.

The hardening score

GuardForge Hardening score works out one number from twenty-one checks of this installation. Every check reads your own site — options, constants, your .htaccess, your user list, WordPress’s own update transients. Nothing is fetched from anywhere, which is also why the score cannot verify a header by fetching your homepage: the score makes no external request of any kind, and that promise is worth more than the extra check.
The one thing in this plugin that reaches the network — the integrity scan’s checksum lookup — is described above, and it is not the score: the score reads what the last scan already worked out and asks nobody anything.

A check that cannot apply here leaves the sum entirely rather than scoring zero. An nginx site has no .htaccess to write, so the two .htaccess checks go to “does not apply” and the remaining checks grow to fill the hundred. Marking a correctly configured site down for lacking an Apache file would be theatre.

Every check sits in one of four weight buckets, and there are no others. 12 is the control whose absence is how sites actually get taken over; 8 is a direct route in, or the loss of the evidence that one was used; 5 is reconnaissance and exposure that shortens somebody else’s work; 2 is worth doing, cheap, and not what the incident report will name. The full table:

https — 12
two_factor_admins — 12
updates_pending — 12
debug_display — 8
xmlrpc — 8
brute_force — 8
file_edit — 8
integrity_baseline — 8
admin_username — 5
user_enumeration — 5
rest_restricted — 5
security_headers — 5
csp — 5
sensitive_files — 5
audit_log — 5
hide_version — 2
directory_listing — 2
login_captcha — 2
pingback — 2
bad_useragents — 2
notifications — 2

The points a row advertises are the points you actually gain: the weights above are shared out over the checks that apply to your site so that they add up to exactly one hundred, and the headline is the sum of what those rows earned. With the Pro add-on installed and licensed, one more row joins the same list — installed plugins and themes with a published advisory, at 12 — and the shares are worked out again around it. Without the add-on that row does not exist and nothing on the screen mentions it.

The public badge

Off unless you switch it on. When you do, GuardForge issues a link on your own site that publishes a letter grade and the month it was worked out — nothing else.

The grade is not your score. It is worked out only from the eleven checks a stranger can already run against your site from outside with no login: the scheme, XML-RPC, whether ?author=1 gives up a login name, whether the REST API hands your user records to anonymous callers, the version in your generator tag, your response headers, your Content-Security-Policy header, whether a directory lists its contents, whether sensitive files answer directly, the login form, and the X-Pingback header. Everything on that list is already public, so the badge tells a passer-by nothing they could not have found by loading your site.

Your numeric score, your two-factor coverage, your brute-force thresholds, your integrity results, whether an account is called admin, your pending updates and any vulnerable components are never published, in any form. The link carries an unguessable token so nobody can walk a list of sites looking for weak ones, it can be reissued or turned off at any moment, views are never logged, and until you switch it on the address is not registered at all — your site answers WordPress’s own 404, exactly like a site without the plugin.

Guard Forge – Security, Login Protection, 2FA & Audit Log

About this plugin