ReportedIP Hive 2.1.21 — Hardening the WordPress Firewall
ReportedIP Hive 2.1.21 caps a 17-release hardening run. Since the firewall landed in 2.1.2–2.1.4, every release from 2.1.5 to 2.1.21 has gone into making that new WAF layer production-grade: the pre-WordPress guard now auto-covers nginx, false positives are cleared from the admin, and a real auto-blocking bug on non-UTC databases is fixed.
The whole detection core stays free and GPL-2.0. Update from Plugins → Check for updates, or download the latest ZIP from the GitHub releases page. If you missed the firewall itself, start with the 2.1.4 firewall release write-up.
What changed since Hive 2.1.4
Seventeen releases shipped between 2.1.5 (2026-06-11) and 2.1.21 (2026-07-03). None added a new pillar — the arc was about hardening the WAF, extended protection and auto-blocking that 2.1.2–2.1.4 introduced.
| Versión | Cambio en el titular |
|---|---|
| 2.1.5 | Fatal ArithmeticError in the CIDR matcher fixed; genuine crawlers no longer blocked as user-enumeration; loopback and private IPs never reported as attackers. |
| 2.1.6 | Verified-bot classifier made three-state, so real Bing/crawler IPs outside the seed range are no longer mislabelled “fake bot”. |
| 2.1.7 | Unified tier badges across the admin; grouped Logs event-type filter; log export JSON/CSV fixed. |
| 2.1.8 | Removing Extended Protection can no longer take a site offline — the guard is neutralised to an inert placeholder, Wordfence-style. |
| 2.1.9–2.1.11 | Backend-managed WAF exceptions: clear a false positive from the admin, no code; self-explanatory exception form and FAQ. |
| 2.1.12 | MainWP provisioning can switch a managed site into Community Network mode. |
| 2.1.13 | Security dashboard reworked into a full analytics view; Hardening Mode no longer triggers on routine background brute-force. |
| 2.1.14–2.1.15 | Auto-blocking made UTC-safe on non-UTC database servers; admin timestamps render in the site timezone. |
| 2.1.16 | Stopped a runaway /relay-quota poll that could fire on every front-end request. |
| 2.1.17 | Extended Protection auto-covers every PHP endpoint on nginx; the guard skips body inspection for signed-in editors. |
| 2.1.18 | “API health degraded” recovers on its own (rolling window); the security log can no longer be flooded by a failure loop. |
| 2.1.19 | Hidden login fixed behind trailing-slash permalinks and page caches (WP Rocket & co.). |
| 2.1.20–2.1.21 | nginx Server Setup instructions surfaced when auto-config is inactive; setup wizard and 2FA copy polished. |
Extended Protection grew up: the pre-WordPress WAF now covers nginx automatically
Extended Protection runs the firewall through an auto_prepend_file guard antes WordPress loads. On nginx that used to mean pasting a hand-written location snippet — which only protects the one block it lands in, so requests handled by their own blocks (wp-login.php, the cached front controller) slipped past the firewall.
Version 2.1.17 detects the PHP-FPM SAPI ahead of the nginx server string and writes a document-root .user.ini instead. PHP-FPM honours auto_prepend_file there for every request regardless of nginx location blocks, with no manual step. The nginx / php.ini snippet stays as the fallback only for stacks without a FastCGI PHP SAPI, and 2.1.20 makes those manual instructions appear whenever the auto-written directive is not yet taking effect.
The guard no longer blocks signed-in editors, or breaks on removal
Because the guard runs before WordPress, it previously inspected every request body — so a logged-in author saving a post through admin-ajax.php or the REST API could trip an XSS/SQLi signature and get a 403. Version 2.1.17 detects the wordpress_logged_in cookie and skips body inspection for authenticated requests (URL and user-agent rules still run), with the in-WordPress engine remaining the capability-aware backstop. Disabling the WAF, or switching it to report-only, now also neutralises the pre-WordPress guard.
Removal is safe now too. Before 2.1.8, deactivating the plugin while the auto_prepend_file directive lived in a file Hive cannot edit (an nginx fastcgi_param or hand-edited php.ini) left PHP pointing at a deleted guard and crashed every request with a 500. Removal now strips the directives Hive controls and leaves an inert placeholder, so a leftover directive can never reference a missing file.
WAF false positives are now cleared from the admin, no code
A signature firewall will occasionally flag a legitimate first-party request — a security plugin that ingests attack-like payloads is the classic case. Versions 2.1.9 through 2.1.11 added a backend-managed exception system that works the way ModSecurity exclusions and the Wordfence allowlist do.
- Every WAF log row carries an Allow action that creates a narrow exception for exactly that rule on that path.
- An exception scopes to a single rule, a rule group, or — for a first-party endpoint — the whole engine on a path, optionally narrowed to an IP/CIDR. A whole-engine exception must always carry a path or IP, so the firewall can never be globally disabled by accident.
- Exceptions are network-wide data (option
reportedip_hive_waf_exceptions,db_version10) and available on every plan — the protection engine itself stays free.
Version 2.1.10 fixed a hoisting bug where the pre-WordPress guard fatally errored on any POST body — body inspection in that layer had been a silent no-op — and made the drop-in honour the same exceptions as the in-WordPress engine. 2.1.11 split the ambiguous “Rule ID or group” field into a Rule ID input and a group dropdown populated from the engine’s known categories, so it is clear what to enter and where the value comes from.
Auto-blocking was silently failing on non-UTC databases
The most consequential fix in this run is 2.1.14. Expiry and attempt timestamps are written in UTC, but were compared against the MySQL session clock (NOW() / CURDATE()). On a server whose database timezone is not UTC, that mismatch meant the per-IP attempt counter never accumulated inside its window — so the failed-login and XML-RPC thresholds were never reached and no offender was ever blocked — while every freshly written block was treated as already expired, leaving the block list empty during an active attack.
Every datetime column and comparison is now UTC-consistent across the database layer, the coordinated-attack detector, the queue recovery sweep, trusted-device expiry and the daily statistics. Version 2.1.15 then made the admin render those timestamps in the site timezone instead of raw UTC, and 2.1.18 moved the API statistics onto the same UTC convention. If your database runs on a non-UTC clock, 2.1.14+ is the release that makes progressive blocking work at all.
Fewer false positives, less log noise, cleaner analytics
Several releases tightened detection so normal traffic stops earning blocks. Version 2.1.13 stopped Hardening Mode triggering on routine background brute-force: the coordinated-attack detectors now count individual failed_login events over a real time window instead of summing each IP’s lifetime counter, with realistic defaults (distributed: 10 distinct IPs and 50 attempts in 10 minutes; burst: 8 IPs and 30 attempts in one minute). The same release reworked the Security dashboard into a full analytics view — a headline strip, a stacked timeline grouped into seven threat families with a 7/30/90-day selector, a doughnut by attack vector, a WAF rule-group bar chart, a severity breakdown and a Top Attackers table.
On the noise side, 2.1.16 stopped a runaway /relay-quota poll that could fire on hot paths (firewall, security headers, bot verification) thousands of times a minute, and 2.1.18 changed “API health degraded” from a lifetime counter that stuck forever to a rolling window over the last 50 calls within 7 days — and throttled repeated api_call_failed rows to one per minute so a failure burst can no longer write tens of thousands of log entries. Version 2.1.19 fixed hidden login for sites on trailing-slash permalinks and behind a page cache, where a cached login page silently dropped the cookie handshake.
How to update to Hive 2.1.21
The built-in update checker polls GitHub every 12 hours; new versions appear on your Complementos screen like any other update. To pull 2.1.21 immediately, open Plugins → Check for updates. There is no schema migration beyond the WAF-exceptions table (db_version 10) added back in 2.1.9, and the setup wizard now walks new installs through Extended Protection with safe defaults.