WordPress security hardening and vulnerability scanning in one dashboard
Per-site hardening, IP ban lists, file integrity monitoring, vulnerability scanning via Wordfence Intelligence, and site-user 2FA, all opt-in and default-off, built so a mistake can never lock you out of your own sites.
Security plugins that are on by default and cannot be undone are a liability, not a safeguard
Hardening rules that cannot be reversed lock operators out of their own sites. Ban lists without an operator allow-list block the person managing the site. File integrity checks without a review workflow advance the baseline past unreviewed changes silently. WPMgr's security suite is default-off, every control has an explicit undo path, and the operator can always recover via wp-config constants.
Under the hood
The steps that make it work, and what each one does.
Enable hardening controls per site
Push hardening rules from the dashboard: disable the file editor, restrict XML-RPC and the REST API, force SSL with HSTS, block PHP in uploads, and protect system files. All controls are opt-in and can be reversed from the dashboard.
Manage the IP and user-agent ban list
Block individual IPs, CIDR ranges, and user agents at early-boot and at the web-server level. The operator allow-list is always honoured so a ban rule can never lock out the operator.
Scan for file changes and vulnerabilities
File hashes are compared against WordPress.org checksums for core, hosted plugins, and themes, and against a learned per-site baseline for everything else. Plugins, themes, and core are checked against the Wordfence Intelligence vulnerability feed with severity, affected version, and CVE references.
Enforce 2FA and password policy for site users
Require TOTP, email codes, or backup codes for chosen WordPress user roles, enforced at the login screen. Set a minimum password strength, block known-compromised passwords, and optionally expire passwords. Grace logins and wp-config recovery constants mean operators are never locked out.
What's included
Every capability ships in the open-source release.
WordPress hardening controls
Disable the file editor, restrict XML-RPC and the REST API, force SSL with HSTS, block PHP in uploads, and protect system files. All opt-in and default-off.
IP and user-agent ban list
Block IPs, CIDR ranges, and user agents at early-boot and at the web-server level. The operator allow-list is always honoured so bans can never lock out the operator.
File integrity monitoring
Hashes compared against WordPress.org checksums and a learned per-site baseline. Changed, added, and removed files are reported and stay flagged until an operator explicitly reviews them.
Vulnerability scanner
Plugins, themes, and core checked against the Wordfence Intelligence vulnerability feed. One-click remediation updates the vulnerable component through the existing update flow. Requires a free Wordfence Intelligence API key.
Client-side encrypted backups
Optional end-to-end encryption for backups: the control plane stores only ciphertext and never holds the decryption key.
Password policy for site users
Set minimum strength, block compromised passwords via a privacy-preserving prefix query, block reuse, and optionally expire passwords with a forced-change screen.
Questions answered
Common questions about this feature.
Can a hardening rule lock me out of my own site?
WPMgr designs every hardening control to have an explicit undo path. Controls are default-off and applied only when you enable them. If a rule causes a problem, it can be reversed from the dashboard. wp-config recovery constants are documented for every control that could affect admin access.
How does the vulnerability scanner work?
WPMgr checks installed plugins, themes, and WordPress core against the Wordfence Intelligence vulnerability feed, which is the same database that powers Wordfence's own scanner. Each finding shows severity, affected version, fixed version, and CVE references. Remediation updates the vulnerable component through the existing update flow. A free Wordfence Intelligence API key is required.
What happens if file integrity monitoring flags a file I intentionally changed?
Flagged files stay flagged until an operator explicitly reviews and accepts the change in the dashboard. The baseline never silently advances past an unreviewed change. Once you accept a change, it becomes the new baseline for that file.
Can the IP ban list lock out the operator?
No. The operator allow-list is always processed before the ban list. An operator IP in the allow-list cannot be blocked even if it also matches a ban rule.
Is site-user 2FA compatible with automated logins?
Yes. Autologin via the WPMgr agent (used for one-click wp-admin access) always bypasses the 2FA interstitial by design. wp-config recovery constants and backup codes provide additional recovery paths.
Run your whole fleet from one dashboard.
Free and open source. No per-site fee. The full release is on GitHub.