Hive 2.1.51: Registration Defence and Access Lockdown for WordPress
ReportedIP Hive 2.1.51 shipped on 9 September 2026 with five new protections, three of them free on every plan. It also closes a hardening-mode gap that had been open since version 2.0.8 and left WooCommerce storefront logins reading the relaxed thresholds during a coordinated attack.
The update installs like any other release. Sites that rely on the WordPress user sitemap should read the last section first.
What is new in Hive 2.1.51
| Feature | Plan | What it does |
|---|---|---|
| Registration defence | Free, wider on Professional | Prohibited usernames, e-mail rules, a per-IP sign-up rate limit, an unknown-username block |
| Access lockdown switches | Free | Turns off the REST API, XML-RPC, feeds, guest wp-admin, PHP in uploads, version fingerprints |
| System readiness register | Free | Twelve detectors for the parts of a setup that fail quietly |
| Account blocking and sessions | Business | Blocks an account without deleting it, lists and terminates active sessions |
| Adaptive two-factor triggers | Professional | Seven per-role step-up rules on new country, IP, network, device or session count |
Registration defence covers every sign-up surface
Until 2.1.51 the registration sensor did one thing: it checked the e-mail domain against a throwaway-mail list. It is a rule set now, implemented in class-registration-guard.php with fifteen options behind it.
- Prohibited usernames on top of a built-in baseline of ten role names, so
admin,administrator,rootand their siblings are refused without any configuration. - E-mail allow or block rules, evaluated alongside the throwaway-mail list. Privacy relays such as Apple Hide My Email and Firefox Relay pass by default.
- A per-IP registration rate limit, three sign-ups per 60 minutes out of the box. The window is capped at 60 minutes because the shared attempt counter restarts every hour.
- An opt-in block for sign-in attempts against usernames that do not exist, which is what credential-stuffing runs produce in volume.
The rules apply to the WordPress registration form, WooCommerce, Multisite sign-ups and users created programmatically, so a theme or plugin calling wp_insert_user() does not slip past them. Ten plain entries per list are free on every plan. Professional lifts the cap, accepts /regex/ patterns and adds allowlist-only registration, where accounts can be created from listed IP ranges and nowhere else. The full option list is in the registration rules documentation.
Access lockdown turns off what the site does not use
Most WordPress installations ship interfaces their owners never touch. A new section on the Firewall page switches them off, free on every plan, every switch off by default:
- The REST API for signed-out visitors, or for everyone outside a chosen set of roles and namespaces.
- XML-RPC together with pingbacks.
- Feeds.
- The admin area for signed-out visitors.
- PHP execution in the uploads folder, written into the uploads
.htaccesson Apache. nginx and unknown servers get the snippet to paste. - The version fingerprints in the page source.
Six of these items joined the hardening score, and the existing weights were lowered so the total still adds up to 100. Scores shift by a few points after the update without any setting having changed. Details: Access Lockdown Switches.
Twelve detectors for the failures nobody notices
A security plugin that has quietly stopped working is worse than none, because the dashboard still looks healthy. The new readiness register watches twelve conditions: an unwritable pre-WordPress guard queue, stalled or disabled cron, a trusted proxy header configured without proxy ranges, an outdated database schema, a degraded community layer, exhausted mail or SMS relay quotas, failing mail delivery, a missing encryption extension and a growing report queue.
Open issues appear on the System Status page with their severity, when they first appeared, a link to the setting responsible and a link to the documentation. Warnings and advisories can be dismissed for seven days, critical issues cannot. The dashboard widget shows the count and wp reportedip status reports them in a new issues field. See System Readiness.
Blocking an account without deleting it
On the Business plan an account can now be blocked from its profile page, from the Users list or with wp reportedip user block. A blocked account keeps its posts, orders and media but cannot sign in, cannot authenticate an application password and cannot complete a password reset. Every session and trusted device it holds is dropped the moment the block is set.
The companion screen under Users, Sessions lists every active session with user, sign-in time, expiry, IP address and device, and terminates a single session or all sessions of a user. Your own current session is never terminable from that list. Blocks stay enforced and can always be lifted, even after a plan expires, so an expired licence can never leave someone locked out. Details: User Account Control and Sessions.
Adaptive two-factor triggers per role
Trusted devices are convenient and they are also the gap an attacker aims for. On Professional, seven step-up triggers can now be armed per role: a new country, a new IP address, a new network, a new device, every N days, every N sign-ins, and more than N concurrent sessions. A user who matches is asked for the second factor again even when the trusted-device cookie is present.
Two guard rails ship with it. Users without a configured method are never locked out, and the administrator role can only be armed after an administrator has completed one two-factor challenge on that site. The 2FA IP allowlist and the reportedip_2fa_bypass filter still bypass the triggers. See Adaptive Step-Up Triggers.
The hardening-mode gap that reached back to 2.0.8
Hardening mode tightens the failed-login threshold network-wide for an hour when a coordinated attack is detected. Two sensors never saw the tightened values: the WooCommerce login monitor, which covers My Account and the classic checkout, and the application-password monitor. Both kept reading the relaxed configuration, so a botnet aimed at the storefront forms ran through an attack the login form would have stopped.
The gap dates back to 2.0.8, when hardening mode first shipped. Sites without WooCommerce and without application passwords were never affected. Both monitors now pass their thresholds through the same clamp as wp-login, as does the admin-side threshold simulation, and a source-level parity test fails the build if a future sensor reads a login threshold without it.
One settings standard: 169 options, 71 of them remote
Seventy options lived outside the settings registry, which meant MainWP and the cloud fleet could not manage them and the JSON export left them out: the security headers, the trusted-proxy pair, the application-password and REST limits, the geo-anomaly window, the WooCommerce login monitor, the hide-login probe, the password policy, the caching and report-queue settings and the footer badge. All of them are registry options now, with one sanitiser instead of several.
Three consequences are worth knowing. All 169 options now carry a one-sentence description, so MainWP and the fleet render real text instead of a bare label. The export catalogue is derived from the registry rather than kept beside it, because the two had drifted apart by fifty-five keys. And an imported settings file can no longer write anything past the sanitiser: the old raw path is gone, which mattered most for the trusted client-IP header, where an arbitrary value is the precondition for spoofing every sensor, the whitelist and the block list at once.
No option key changed, so stored fleet policies and per-site overrides survive the update untouched. Both dashboards need one schema reload to show the new grouping.
Before you update: the user sitemap disappears
One change will surprise people. wp-sitemap-users-1.xml no longer exists while user-enumeration blocking is active, and that option is on by default, so most sites lose the file with this update. It is deliberate: the same defence already blocks ?author= and the REST user route, and the sitemap was the one remaining published list of usernames on the site. Search engines do not need it, and author archive pages stay crawlable if you keep them public under Protection, Detection.
Getting 2.1.51
The Full Edition polls GitHub Releases every 12 hours, so the update appears on the Plugins page on its own. To pull it immediately, download the ZIP from the 2.1.51 release on GitHub and upload it over the existing installation. Migrations run idempotently on activation; the database schema is at version 16.
- Full plugin documentation, including the twelve readiness detectors and the WP-CLI reference
- Plans and what each tier unlocks, if you are weighing Professional or Business