ReportedIP Hive 2.1.49: Security Audit, Settings Standard and Fleet Management
Eight releases shipped between 14 and 26 August 2026. The series starts with a security release that closed three proven bypasses in the firewall and the 2FA layer, and ends with fleet management: one security policy, pushed to every site you run, from MainWP or from your reportedip.com account.
What changed between Hive 2.1.41 and 2.1.49
- 2.1.44 closed nine security findings, three of them demonstrated bypasses of the block gate, the firewall and the 2FA login.
- 2.1.45 made every API request identify its installation the way wordpress.org update checks do, and added a licensed-domains card to the dashboard.
- 2.1.46 restored plugin updates for remote-management dashboards, which had been blind to Hive updates since 2.1.32.
- 2.1.47 introduced the settings registry and a versioned remote-settings protocol, so a dashboard can read and apply Hive settings with per-key validation.
- 2.1.48 added cloud fleet management for Business, an Ed25519-signed transport that lets reportedip.com apply policies to your sites.
- 2.1.49 hardened that endpoint so an unauthenticated caller cannot tell whether a site has opted in.
Everything here is in the free plugin unless a line says otherwise. The protection engine stays free, as always.
2.1.44 closed three bypasses that were proven against a live site
This release came out of a full audit of the request path. Three findings were not theoretical. Each one was reproduced against a running installation before the fix went in.
admin-ajax.php sat outside the block gate
The IP gate and the firewall both ran on init, but admin-ajax.php was treated as an admin request and skipped. A blocked address could keep calling any public AJAX action, and plugins that expose logic through AJAX were reachable while the same address was locked out of the front end. Both layers now inspect admin-ajax traffic.
One firewall exception could hide every rule behind it
Exceptions are meant to whitelist a single rule for a single path. A malformed scope stopped the engine from evaluating the rules that followed, so one bad entry silently switched off part of the ruleset. Exception matching is now scoped per rule and cannot terminate the run.
Percent-encoded probes walked past three sensors
The scan detector, the user-enumeration guard and the hide-login probe all compared paths after sanitize_text_field(), which leaves percent escapes intact. A request for %2E%2E%2Fwp-config.php did not match the honeypot list. Path comparison now happens on the decoded value.
Six more findings in the same release
- A submitted 2FA method was never checked against the factors the user actually has enrolled. A login could name a method the account never set up.
- TOTP codes were not single-use. A code captured in transit stayed valid for the rest of its 30-second window.
- Both public 2FA REST routes end in
wp_set_auth_cookie()and accepted cross-origin calls. They now refuse a browser form post from another origin. - Blocks and unblocks took up to five minutes to apply because the access verdict was cached. The cache is invalidated on every block change.
- A configured client-IP header was honoured from any peer. Trusted proxy source ranges now gate whether the header is read at all.
- A malformed CIDR prefix made the pre-WordPress guard match every address.
If you run Hive on a site with public AJAX endpoints or behind a reverse proxy, 2.1.44 is the release you do not want to skip.
Remote dashboards were blind to Hive updates since 2.1.32
A performance change in 2.1.32 skipped the update checker on front-end requests. MainWP, ManageWP and comparable tools sync over exactly those requests, so they never saw a new Hive version and could neither report nor install it. Sites that relied on a management dashboard for updates sat on old builds without any warning.
2.1.46 runs the update checker in every request context again and turns on WordPress auto-updates for the plugin. A security plugin that cannot update itself is a liability, so this is no longer optional. If your fleet looked up to date on 2.1.32 through 2.1.45, check the installed version now.
Every request now says which installation it comes from
Since 2.1.45 each API call carries the site address and the plugin and WordPress versions, in the same format wordpress.org update checks have used for years. On multisite the network address is sent once, so a network counts as one domain rather than one per subsite.
The Security Dashboard gained a licensed-domains card that shows how many domains your plan covers and how many are in use. Retired sites can be released from the account area, and domains that stop reporting are released automatically after 60 days. Third-party services never receive this identity. The HIBP password check in particular gets the bare product token and nothing else.
One settings standard for every writer
Hive settings used to be validated in four different places. The settings page had its own sanitizers, the setup wizard had a second set, the import had a third, and none of them existed outside wp-admin. A remote write could land in the database without the checks a form submission would have run.
2.1.47 replaced that with one declarative registry. Every managed option states its kind, range, allowed values, plan requirement and side effects once. The settings page, the wizard, the import and every remote transport validate through the same pipeline, and the registry loads in every request context. Rewrite-rule flushes and cache resets now fire for whichever writer changed the value, including WP-CLI.
On top of that sits a versioned remote-settings protocol. A dashboard asks a site for its settings schema, reads the current values, and applies a batch. Every key comes back with its own result, so a plan-gated option is reported as skipped instead of failing the whole push. The contract is documented in the plugin repository and both dashboards implement it.
Fleet management: one policy for every site you run
2.1.48 turned that protocol into a feature. Define a security policy once, override single fields where a site needs something different, and push it. The dashboard manages 63 settings across seven groups, covering detection thresholds, blocking and escalation, the firewall level, hide-login, 2FA policy, logging and retention, and notifications.
Each site reports a fingerprint of its managed settings on every API call. Change something directly on a site and it shows up as drifted until you push again. A compare view puts the target value next to the value the site actually has, fetched live.
There are two ways to drive it. The MainWP bridge ships inside Hive, so a site connected to your MainWP dashboard is manageable with no extra child plugin and no extension to buy. The reportedip.com fleet dashboard does the same from your account under Domains and needs no MainWP at all. That one is part of the Business plan.
How the cloud transport is secured
Letting a service write settings into your site is only acceptable if the site can prove who is asking. The transport is off by default and every request has to clear seven checks before anything is written.
- The site owner switches it on. Without the toggle, Community mode and an access key, every request is refused.
- Per-IP rate limiting on the site.
- An Ed25519 signature over the exact payload, verified against a public key bundled in the plugin. The private key never leaves the service.
- A five-minute freshness window on the request timestamp.
- Single-use request identifiers, so a captured request cannot be replayed.
- An audience binding, so an envelope addressed to one site is rejected by any other.
- A proof derived from the site’s own access key, binding the request to the account that owns the site.
2.1.49 added one more property. A request that fails the signature check and a request to a site that never enabled the feature now get the identical generic error, so scanning the internet no longer reveals which sites have fleet management switched on. The real reason is recorded in the site’s security log.
Smaller fixes worth knowing about
- Network activation no longer fatals on multisite when extended protection is enabled.
- Failed XML-RPC app-password logins counted twice against the brute-force threshold. One wire attempt is now one attempt.
- The logs filter knows the App Password Failed event type.
- Release highlights in the update banner stopped mid-sentence when the release notes were long.
- The Reset API statistics button on the Security Dashboard did nothing. Its handler was only bound on the System Status page.
- Admin pages no longer scroll sideways on phones. Tables scroll inside their own container, and card headers wrap.
How to update to Hive 2.1.49
Updates arrive through the normal WordPress update screen. Since 2.1.46 auto-updates are enabled for the plugin, so most installations will already be on 2.1.49 or will get there within a day. To pull it immediately, open Plugins and use the check-for-updates link, or update from your management dashboard.
No configuration changes are required. Cloud fleet management stays off until you switch it on per site, and the trusted-proxy setting keeps its previous behaviour until you fill in the source ranges. If you were running anything between 2.1.32 and 2.1.45, verify the installed version by hand once, since your dashboard may have been reporting an outdated number.