WordPress Plugin — ReportedIP Hive (Full Edition)

ReportedIP Hive is a community-powered WordPress security plugin. It turns every protected site into a sensor: when one site is attacked, the hive learns and every other site can refuse the attacker before the first request lands. Real-time threat intelligence, sixteen attack sensors including a Web Application Firewall, four-method 2FA, progressive block escalation and server-delivered, signed firewall rulesets. Open source, published under GPLv2+ on GitHub.

Installation

Setup Wizard (10 steps)

The wizard runs on first activation and can be re-launched any time from the plugin settings. Each step persists immediately server-side on every navigation (Back included), so you can stop and resume without losing a setting.

Operating Modes

Two modes — switch between them at any time without losing local data.

What you get on each tier

The Hive plugin itself is fully functional on the Free tier — local protection, all sixteen sensors, all four 2FA methods. Paid tiers bundle managed delivery infrastructure (mail and SMS) and higher Community-Network quotas. See the Pricing page for the full comparison and to upgrade.

Business is multi-bookable. Every Business figure above is per licence. Book Business x2, x5, x10 or x20 at checkout (or change it later in the Stripe Customer Portal) and the per-day checks/reports, the monthly 2FA mail/SMS allowance and the domain count all scale with your licence count — e.g. x5 = 75 domains and 500,000 checks/day. A volume discount applies automatically from x2 upwards. PRO stays single-licence; Enterprise figures are unlimited (fair use) and are never multiplied.

Bundle consumption order (PRO and Business): first the monthly included allowance (25 SMS / 500 mails on PRO, 75 / 2,500 on Business), then the prepaid bundle balance. Once both are exhausted the API returns HTTP 429 and Hive falls back to local wp_mail() for mail (or hard-caps SMS) — other 2FA methods stay operational. Bundle credits never expire. Stripe uses tax_behavior = inclusive for the gross-priced bundles (PAngV compliant); Reverse Charge / OSS is handled automatically by Stripe Tax.

6-Layer Defence

Hive applies its checks in order — each layer can short-circuit the request before it reaches the next. Hooked on init at priority 1 so that other plugins do not run for a blocked IP.

1. Whitelist — trusted IPs and CIDR ranges are always allowed (your office, monitoring services, …).
2. Local block list — IPs you have blocked manually, or that exceeded local thresholds. Stored in wp_reportedip_hive_blocked.
3. Web Application Firewall — the active WAF ruleset is matched against the URI, query, body and user-agent; a hit is blocked through the shared, reference-coded 403 path. Whitelist- and content-author-aware to avoid false positives. An optional pre-WordPress drop-in can run this layer before WordPress even loads.
4. Attempt counters — login, comment, XMLRPC, REST-burst and 404-scan counters trigger an automatic block once the threshold is reached.
5. Community reputation — in Community Network mode, IPs with confidence ≥ threshold are blocked at the edge.
6. 2FA challenge — protected accounts must complete a second factor to log in.

The Sixteen Attack Sensors

Every sensor can be toggled and tuned independently in Settings → Protection. The final two rows — block escalation and the WooCommerce login bridge — are companion mechanisms riding the same pipeline rather than separate sensors: escalation is the response ladder every sensor feeds into, and the WooCommerce bridge counts storefront login failures toward the existing brute-force sensor.

Progressive Block Escalation

Repeat offenders pay more. The default ladder is 5 min → 15 min → 30 min → 24 h → 48 h → 7 d. After 30 days clean the counter resets to step 1. First-time tripping legitimate visitors (CGNAT, fat-fingered admins, mobile-network egress) recover in minutes; persistent attackers reach the 7-day step.

The ladder, the reset window and the master toggle live under Settings → Blocking → Progressive blocking. The wizard's Protection step exposes the master toggle so fresh installs are escalation-aware from the first save. The fixed block_duration setting still applies when the ladder is toggled off. Sub-hour granularity is provided by ReportedIP_Hive_Database::block_ip_for_minutes().

Web Application Firewall & Rule Delivery

Since 2.1.2 Hive ships a request-inspecting Web Application Firewall. On init it matches the active waf ruleset against the URI, query string, request body and user-agent and blocks a hit through the shared, cache-safe, reference-coded 403 path. It is ReDoS-hardened (bounded PCRE backtracking, fail-open on a malformed rule), whitelist- and content-author-aware to avoid false positives, and adds roughly 4 µs of CPU per request with zero extra database queries when a persistent object cache is present.

The rules are not hard-coded in the plugin. They are delivered from the reportedip.com Rule API — server-delivered, versioned, Ed25519-signed and tier-staggered across four rulesets (waf, bot_signatures, disposable_domains, scan_paths). The plugin verifies every ruleset against a bundled public key before applying it and always falls back to a bundled baseline, so a tampered, oversized or unreachable feed can never poison your rules. New attack signatures reach all installations within hours, with no plugin release required.

• Free on every plan — the WAF engine and the OWASP-Top-10 Paranoia-Level-1 baseline ruleset, fully usable offline in Local Shield mode from the bundled baseline.
• Priority Sync (Professional and up) — the deeper, frequently-updated, signed Paranoia-Level-2/3 rulesets (obfuscation and bypass coverage) plus the live bot-IP-range and disposable-domain feeds. Free syncs the bundled baseline; Contributor weekly; Professional and above daily.
• Extended Protection drop-in (optional) — a pre-WordPress auto_prepend_file guard that runs the WAF before WordPress loads. Apache (.htaccess) and PHP-FPM stacks — including nginx + PHP-FPM — are auto-configured via a document-root .user.ini, which covers every PHP endpoint regardless of nginx location blocks (since 2.1.17); stacks without a FastCGI PHP SAPI get a php.ini / hosting-panel auto_prepend_file line or an nginx fastcgi_param snippet from the Server Setup tab. The guard skips request-body inspection for authenticated requests by default, so signed-in editors saving content never trip it; URL and user-agent rules still run, and the in-WordPress engine remains the capability-aware backstop. Off by default; removal strips the directives Hive controls and neutralises the guard to an inert placeholder instead of deleting it (since 2.1.8), so a leftover directive in a hand-edited php.ini or nginx config can never point at a missing file and 500 the site. Disabling the WAF engine or switching to report-only also neutralises the guard automatically.
• Reference codes — every block (WAF or sensor) carries a correlatable code such as WAF_SQLI-3F9A2B71, shown on the block page and emitted as the X-RIP-Ref header. A wrongly-blocked visitor quotes one short string that an admin matches in the logs; the token is a one-way hash of IP, reason and hour, so no personal data is exposed.

Configuration and live status live under the dedicated Firewall menu: an Overview mini-dashboard (per-module status, 7-day counters, recent firewall events), a WAF tab (engine / mode / Paranoia-Level selector), a Bot Verification tab, a Spam Defence tab (disposable-email + honeypot), a Rule Sync status view and a Server Setup tab that gathers every web-server snippet in one place.

WAF Exceptions — Handling False Positives

Since 2.1.9 a false positive can be relieved from the admin without touching code — the way ModSecurity exclusions and the Wordfence allowlist work. A first-party endpoint that legitimately receives attack-like payloads (a form that accepts HTML, a security API ingesting reported attack data, a page builder posting raw markup) occasionally trips an injection signature; an exception makes that one case pass while the engine keeps protecting everything else.

• Where. Firewall → WAF → WAF Exceptions, plus a one-click "Allow" action on every WAF log row that pre-fills a narrow exception for exactly that rule on that path — no need to know the rule ID by heart.
• Scopes. An exception targets a single rule (by rule ID, taken from the WAF block log), a rule group (picked from the engine's known categories) or — for a first-party endpoint — the whole engine on a path, optionally narrowed to an IP or CIDR range. A whole-engine exception must always carry a path or IP restriction, so the firewall can never be globally disabled by accident.
• Scope it as tightly as possible. Prefer a single rule on a path over a rule group, and a rule group over a whole-engine exception. The block log records the matched value, inspected target, request method, URI and user-agent (since 2.1.11), so you can see exactly which rule fired and why before you allow it.
• Extended Protection honours the same list. Active exceptions are baked into the pre-WordPress drop-in guard and rebaked whenever the allowlist changes — the pre-WordPress layer and the in-WordPress engine never disagree.
• Multisite & plans. Exceptions are network-wide data, available on every plan — the protection engine itself stays free.
• Developer escape hatch. apply_filters('reportedip_hive_waf_bypass_routes', []) excludes REST routes at code level. Matching is an anchored prefix test against the resolved WP REST route — never an unanchored substring of the raw URI — so a bypass token smuggled into an unrelated query parameter cannot disable the WAF.

Verified Bot Detection, Disposable-Email Blocking & Comment Honeypot

• Verified bot detection (free). Confirms that a request claiming to be Googlebot, Bingbot or another crawler genuinely originates from it — a DNS-free match against the crawler's official IP ranges first (Priority Sync), then a forward-confirmed reverse-DNS fallback that resolves both A and AAAA records. Spoofers are flagged (default) or blocked; a genuine crawler is never blocked. facebookexternalhit is verified against Meta's published IP ranges.
• Disposable-email blocking (free). Inspects the address on registration (WordPress and WooCommerce) against the throwaway-mail list. Three modes — off / monitor / block. Privacy relays (Apple Hide My Email, Firefox Relay, …) are a distinct category that passes through by default. The live list rides Priority Sync.
• Comment honeypot (free). An invisible, screen-reader-excluded decoy field on the comment form; spam bots that fill every field are rejected with no CAPTCHA friction for real visitors.

Security Headers

Hardening response headers on every front-end request. Headers already sent by your server or another plugin are detected and left untouched.

• Basic trio (free) — X-Content-Type-Options, X-Frame-Options, Referrer-Policy.
• Advanced (Professional) — HSTS, Permissions-Policy, a Content-Security-Policy (report-only by default, with a builder) and the cross-origin isolation trio (COOP / CORP / COEP).

The Server Setup tab can additionally export the configured headers as server-level nginx add_header / Apache Header directives.

Protection & Hardening Score

Two dashboard gauges (0–100 plus an A+–F grade, Mozilla-Observatory style) rate your detection coverage and your hardening posture, with per-item deep links to switch a sensor on. Locked (paid) features count toward the visible potential, not against your score — so the free tier can still reach a top grade.

Security Dashboard & Analytics

The main dashboard opens with a headline strip — attacks blocked over the last 30 days, attacks blocked today, IPs currently blocked and how many of your protection layers are switched on (for example 17 / 20). Below it, the analytics pull from every sensor, not just the classic login / spam counters.

• Security Events timeline. A stacked-area chart grouping all activity into seven families — Login & Credential, Firewall (WAF), Scanners & Probes, Fake Bots, Recon & Enumeration, Spam & Flooding and Anomalies — over a selectable 7-, 30- or 90-day window.
• Threat Distribution. A breakdown of which attack family dominated the period, so you can see at a glance whether you are facing brute-force, firewall-level exploit attempts, scanners or spam.
• Firewall — Top Attack Types. The WAF blocks ranked by rule group (SQL injection, cross-site scripting, path traversal, Log4Shell, scanner user-agents, …).
• Severity Breakdown. Critical / High / Medium / Low counts, so the volume of serious events is never hidden inside a single total.
• Top Attackers (30 days). The most active source IPs with their hit count, when they were last seen and whether they are currently blocked or only monitored.
• Recent Activity. The live event stream, each entry tagged with its severity and threat family plus the relevant detail (matched WAF rule, probed path, spoofed bot name).

All counts are real on every plan — the dashboard reflects what your site actually blocked. Professional and Business plans add deeper analytics on top (longer history and log retention, attacker geography and the compliance-grade audit trail described below).

Audit Event Trail (Business)

An append-only user-lifecycle trail — logins, failed logins, password resets, profile updates, role changes (including the acting user), registrations and new-IP detection — with filters, CSV / JSON export, WordPress GDPR export/erasure integration and retention cleanup (1 year on Business, configurable on Enterprise). Stored in the dedicated audit_log table (schema v9). The standard 30-day security logs stay available on every plan; the audit trail is the compliance-grade record on top.

MainWP Integration

Hive is remote-manageable from a MainWP dashboard with no extra child plugin and no MainWP extension to buy. It hooks the MainWP Child mainwp_child_extra_execution filter, so every job is authenticated by the existing MainWP Child channel — no additional credentials, no new attack surface. Setup is simply: install MainWP Child and Hive on the managed site, connect the site to your MainWP dashboard as usual, done.

Two job types are answered:

• Security-metrics sync — aggregate counts only: active blocks, whitelist size, failed logins, comment spam, reputation blocks, queue size, recent critical events, 2FA-enabled users. Since 2.1.6 the sync also reports the firewall posture (waf_enabled, waf_report_only, waf_dropin_enabled, waf_dropin_running, waf_server and a derived waf_needs_setup flag), so a dashboard can flag sites whose Extended Protection is enabled but not yet running — typically an nginx host still waiting for its server snippet.
• Provisioning (reportedip_hive_provision) — push an API key to a managed site from the trusted dashboard, and since 2.1.12 optionally switch it into Community Network mode in the same job (community flag). The sync job reports each child site's current operation_mode.

No IPs, usernames, secrets or the API key ever leave the managed site — the sync payload is counts and status flags only.

Multisite Networks

The Full Edition is network-only (Network: true, since 2.0.0): per-site activation is hidden by WordPress so the security configuration stays uniform across the network. All nine tables live under $wpdb->base_prefix, which makes every threat decision network-wide — cross-site brute-force attempts aggregate into one central counter, and a single block locks the IP out of every sub-site at once.

• Network Admins get the full settings surface and an all-sites Logs view.
• Site Admins on a sub-site get a read-only Status / Logs UI plus exactly two writable per-site overrides: the Frontend-2FA slug and additive 2FA-enforcement roles (a sub-site can enforce 2FA for more roles, never fewer).
• Cron runs only on the main site — no duplicate syncs or cleanup sweeps per sub-site.
• WAF exceptions are network-wide data, managed by the Network Admin.

Two-Factor Authentication (2FA)

Four methods are supported and can be combined per user. Recovery codes are generated on first setup. Secrets are encrypted at rest (libsodium with an OpenSSL fallback).

• TOTP — RFC 6238 (6 digits, 30-second window). Works with Google Authenticator, Authy, 1Password, Bitwarden, …
• Email — six-digit OTP via the configured mail provider; rate-limited (3 codes per 15 min, 5 verify attempts per code, 60 s resend cooldown).
• SMS — six-digit OTP via the managed reportedIP SMS relay (Professional plan and up; see below). Phone number is encrypted at rest.
• WebAuthn — passkeys, security keys (YubiKey), platform authenticators (Touch ID, Face ID, Windows Hello). In-house CBOR parser, no external dependency.
• Trusted devices — opt-in remember-this-device tokens with configurable expiry (default 30 days). Stored in wp_reportedip_hive_trusted_devices as SHA-256 hashes.
• Recovery codes — 10 single-use xxxx-xxxx codes; low-codes warning at ≤ 3 remaining.

Hardware security keys (YubiKey)

Since the 2.1.33–2.1.36 series, hardware FIDO2 keys are a first-class citizen: the YubiKey 5 series (USB-A, USB-C, Lightning and the NFC models tapped against a phone), the Security Key by Yubico line and every other CTAP2 authenticator work on all three challenge surfaces — the wp-login interstitial, the WooCommerce storefront challenge and the password-reset gate. Older U2F-only keys (CTAP1) are not officially supported.

• Setting it up — open your profile page (Users → Profile → Two-Factor Authentication), choose Add security key → Security key (USB / NFC), give the key a name, then insert it and touch the gold contact when the browser prompts. On a phone, hold the key flat against the back near the top (NFC). No FIDO2 PIN is required for enrolment.
• One key per account is free. The Business plan adds Advanced Security Keys: several keys per account — register a second YubiKey and keep it in a safe place as a backup — plus automatic model detection ("YubiKey 5 Series with NFC" shown next to the key) and email alerts whenever a key is added or removed.
• Lost your key? Sign in with one of your recovery codes (or your backup key on Business), then remove the lost key on your profile page. Removing the last key disables the method cleanly.
• Clone detection — every sign-in advances the key's signature counter. An assertion whose counter does not advance is rejected, logged and reported to the account owner by mail on every plan.
• Algorithms — ES256 on every key; Ed25519 is negotiated automatically on YubiKey firmware 5.2.3+ when the server has libsodium.

2FA brute-force protection

The 2FA verifier ladder is 3 → 30 s, 5 → 5 min, 10 → 30 min, 15 → 1 h. When the count reaches the top step the IP is graduated to the central auto_block_ip() path (event 2fa_brute_force) which trips progressive escalation and Community-mode reporting like any other sensor.

Headless 2FA REST

For app integrations the plugin exposes three routes under namespace reportedip-hive/v1:

• POST /2fa/challenge — username + password → challenge token + enabled methods (20 req / 5 min per IP).
• POST /2fa/verify — token + method + code → sets the auth cookie (30 req / 5 min per IP).
• GET /2fa/methods — introspect active methods for the current user.

WooCommerce Frontend Login

Hive's frontend 2FA stays inside your active storefront theme — customers logging in through [woocommerce_my_account], the classic checkout or the WooCommerce Cart / Checkout blocks complete their second factor on a themed page. The cart and checkout state survives the redirect roundtrip, the trusted-device cookie is shared with the wp-login flow.

• Configuration path — 2FA → Frontend login for WooCommerce.
• Configurable slugs — challenge slug (default reportedip-hive-2fa) and setup slug (default reportedip-hive-2fa-setup); both editable, conflict-checked, and rewrite rules flush automatically when changed.
• Tier downgrade — soft-disable on Free and Contributor plans; settings, slug choices and onboarding state are preserved, no data loss when re-upgrading.
• Conflict detection — Hive surfaces an admin notice when Solid Security, the WP Two-Factor plugin or Wordfence 2FA owns the login form, and disables the frontend challenge to avoid double-prompts.
• Plan availability — Professional and above. The free WooCommerce login-failure sensors (woocommerce_login_failed, woocommerce_checkout_login_form_failed_login) remain on every plan and continue to feed the brute-force counter.

Mail and SMS Delivery

The mail layer runs through a pluggable provider contract (ReportedIP_Hive_Mailer). The default provider is WordPress wp_mail(); integrators can swap in their own without touching the rest of the plugin. On Professional and above, transactional mail (2FA codes, security notifications) can instead ride the managed reportedip.com mail relay — SPF-, DKIM- and DMARC-aligned sender infrastructure, so OTP mails do not land in spam the way an unauthenticated wp_mail() from shared hosting often does.

• SMS 2FA is a Professional feature delivered exclusively through the managed reportedip.com relay — no own SMS account, Twilio credentials or carrier contract required. It is configured automatically with a paid plan; enable it under Settings → 2FA → SMS. Per-recipient resend backoff climbs gently (0 s → 30 s → 1 m → 2 m → 5 m → 15 m), so a slow or missed SMS can be re-requested without punishment while a genuine burst is still throttled.
• Monthly allowances and prepaid bundles. PRO includes 25 SMS / 500 mails per month, Business 75 / 2,500 (per licence). Prepaid bundles top that up — see the tier table above for prices and the bundle consumption order paragraph for exactly what happens when a quota runs out (spoiler: mail falls back to local wp_mail(), no 2FA method ever goes dark).
• Custom-branded mail templates (Business and up). Business unlocks white-label transactional mail — your logo, colours and sender identity on 2FA and notification mails instead of the ReportedIP branding, matching the white-labelled setup wizard and 2FA pages.

Configuration Overview

All settings live under ReportedIP Hive → Settings. The most important defaults:

Database Tables

Nine tables, created on activation and prefixed wp_reportedip_hive_. Schema version 13, with idempotent step-by-step migration on every plugin update; opt-in delete on uninstall. On Multisite every table lives under $wpdb->base_prefix so threat decisions apply network-wide.

• logs — security events, JSON details, severity, reported-flag; the source for the dashboard analytics (7- / 30- / 90-day trends, family and severity breakdowns, top attackers).
• whitelist — trusted IPs and CIDR ranges; expiry optional.
• blocked — active blocks (manual / automatic / reputation), with blocked_until.
• attempts — per-IP counters per attempt type, with first/last timestamps.
• api_queue — pending and failed reports to the community API; retry logic.
• stats — daily aggregates (failed logins, blocks, spam, XML-RPC, reputation) for trend summaries and reports.
• trusted_devices — 2FA device tokens (SHA-256 hashes), IP and device name, expiry.
• audit_log — append-only user-lifecycle audit trail (Business); added in schema v9.
• waf_exceptions — the backend-managed WAF allowlist (rule / group / path scope, optional IP/CIDR); added in schema v10, network-wide.

Frontend Shortcodes & Auto-Footer

Embed a small "protected by Hive" badge anywhere on the site. All shortcodes render a single <rip-hive-banner> web component and pull live numbers from a 6-hour transient cache (no API call per page view).

• [reportedip_badge] — small badge (default protect tone).
• [reportedip_stat] — single statistic (default trust tone).
• [reportedip_banner] — wide banner (default community tone).
• [reportedip_shield] — shield icon (default contributor tone).

Common attributes: stat (e.g. attacks_30d, reports_total), tone (protect / trust / community / contributor), color, background, label, intro. The auto-footer in the wizard uses the same component with a configurable variant and alignment.

WP-CLI Reference

The 2FA tooling is fully scriptable. Available under wp reportedip 2fa …:

wp reportedip 2fa status [--user=<id>]
wp reportedip 2fa enable <user_id> --method=<totp|email|sms|webauthn> [--secret=<base32>]
wp reportedip 2fa disable <user_id> [--method=<m>]
wp reportedip 2fa reset <user_id>
wp reportedip 2fa enforce --role=<role> [--remove]
wp reportedip 2fa audit [--user=<id>] [--since=<date>]
wp reportedip 2fa cleanup

Cache-Plugin Compatibility

Since 1.5.2 the blocked-page response defines DONOTCACHEPAGE, DONOTCACHEDB and DONOTCACHEOBJECT (respected by WP Rocket, W3 Total Cache, WP Super Cache and LiteSpeed Cache) and emits explicit Cache-Control: no-store, no-cache, must-revalidate, max-age=0, Pragma: no-cache plus the WordPress core nocache_headers() set. A single blocked attacker can no longer pollute the page cache with a 403 that legitimate visitors would otherwise receive until the cache expires.

Filters and Action Hooks

• apply_filters('reportedip_hive_external_url', $url, $context) — replace any of the external URLs (privacy policy, registration, FAQ, …).
• apply_filters('reportedip_hive_rest_bypass_routes', $routes) — extend the list of REST-route prefixes that bypass the burst monitor (cookie-banner integrations).
• apply_filters('reportedip_hive_scan_paths', $paths) — extend the honeypot path list for the scan detector.
• apply_filters('reportedip_hive_decoy_paths', $paths) — extend the decoy-path bait list.
• apply_filters('reportedip_hive_waf_bypass_routes', $routes) — exclude REST routes from the WAF at code level (anchored prefix match against the resolved route; empty by default). Prefer the backend-managed WAF exceptions for one-off false positives.
• apply_filters('reportedip_hive_mail_provider', $provider) — swap in your own mail provider (implement interface-mail-provider.php).
• do_action('reportedip_hive_ip_blocked', $ip, $reason) — fired when an IP is blocked.
• do_action('reportedip_hive_report_queued', $ip, $category) — fired when a report is enqueued for the API.

Frequently Asked Questions

The questions we get most often. Each answer links back to the relevant section above where appropriate.

General

Installation & Setup

Modes & Sensors

2FA

Performance & Compatibility

Privacy & GDPR

Customisation & Extension

add_filter('reportedip_hive_rest_bypass_routes', function ($routes) {
    $routes[] = '/my-consent-plugin/v1';
    return $routes;
});

add_filter('reportedip_hive_scan_paths', function ($paths) {
    $paths[] = '/.aws/credentials';
    return $paths;
});

Quotas, Plans & Account

Troubleshooting

Plugin does not block any IPs

Check whether Report-Only Mode is enabled — it logs threats without blocking. Also verify that the block threshold is not set too high (default 75 %) and that Auto-blocking is on (the duration strategy is disabled while auto-blocking is off).

API connection errors in Community Network mode

Ensure your server can make outbound HTTPS requests to reportedip.com. Some hosts block outgoing connections by default. Verify the API key on the Dashboard.

Cookie-banner visitors get blocked

Since 1.5.0 the four common consent namespaces (real-cookie-banner, complianz, borlabs-cookie, cookie-law-info) are bypassed by default. If your stack uses a different namespace, extend the bypass list via the reportedip_hive_rest_bypass_routes filter.

Legitimate users get blocked

Add their IP addresses or CIDR ranges to the local whitelist. Whitelisted IPs are never blocked, regardless of reputation.

The firewall blocks a legitimate request (WAF false positive)

Open Firewall → WAF, find the block in the log (the visitor's X-RIP-Ref reference code from the block page matches a log row) and click Allow — it creates a narrow exception for exactly that rule on that path. See WAF Exceptions for scoping guidance. Exceptions apply to the pre-WordPress Extended Protection guard as well.

Extended Protection is enabled but shows "not running"

Typical on nginx hosts where the auto-written .user.ini directive is not picked up (e.g. user_ini.filename disabled, or the document root is not the scan path). The Firewall → Server Setup tab surfaces the manual options: the PHP-FPM-pool / php.ini auto_prepend_file line or the nginx fastcgi_param snippet. The status is verifiable — it reports whether the guard actually executed for the current request. The in-WordPress engine protects the site either way; the drop-in only moves the same checks earlier.

High API usage / running out of checks

Responses are cached locally (with ETag) for 24 hours by default. If you are still running out of checks, increase cache_duration or upgrade your plan. Monitor the queue and quota on the Dashboard.

Locked out by 2FA

Use one of the recovery codes saved during 2FA setup. If those are lost, an administrator can reset 2FA for any user under Users → Two-Factor. As a last resort: wp reportedip 2fa reset <user_id>.

Since 2.1.22 an enforced user who never set up 2FA is no longer locked out by default: once grace period and skips are exhausted they are signed in and sent straight into forced enrolment (no skip option). Administrators and Multisite super admins can never be hard-locked out, even if you switch the policy back to Block sign-in.

The block editor (Gutenberg) keeps getting throttled

The block editor fires 50+ REST calls in a few seconds. Since 1.2.2 logged-in users skip the global REST-burst monitor; only anonymous bursts count. Make sure you are running 1.2.2 or newer.

GDPR & Privacy

The plugin is designed with privacy in mind and is fully GDPR compliant.

• Local Shield mode: No data leaves your server. All detection and blocking happens locally.
• Community Network mode: Only attacker IP, threat category and timestamp are shared. No usernames, no passwords, no comment content, no end-user data.
• User-agents are truncated to 50 characters before storage.
• Automatic cleanup: Security logs are deleted after the configured retention period (default 30 days). Auto-anonymisation kicks in earlier (default 7 days).
• Encryption at rest: TOTP secrets, WebAuthn credentials and SMS phone numbers are encrypted with libsodium (OpenSSL fallback).
• No tracking: No cookies, no tracking pixels, no telemetry.
• WordPress privacy tools integration: Hive registers a personal-data exporter and eraser with WordPress core, so Tools → Export / Erase Personal Data requests automatically include Hive's records for the requested subject (log rows, trusted devices, audit-trail entries). It also contributes a suggested paragraph to the WordPress privacy-policy guide (Settings → Privacy → Policy Guide) that you can copy into your own policy.
• Open source: The full source code is published on GitHub — every line is auditable.

Changelog Highlights

• 2.1.33 – 2.1.36 — Official YubiKey / hardware security-key support: full WebAuthn ceremonies on all three challenge surfaces, a multi-key manager with attestation-based model detection (Business), cloned-key detection via signature-counter regression with mail alerts on every plan, Ed25519 when libsodium is available, and a rebuilt plain-language profile 2FA section with a user-selectable default method.
• 2.1.26 – 2.1.32 — Verified-crawler cross-checking (a spoofed Googlebot user-agent buys nothing), a central never-block-a-verified-bot guard, community-reputation blocks that cover every surface, self-block prevention for the server's own addresses, volume-weighted block escalation, and the performance release: 36 → 11 queries per request, an 8 KB blocklist header read and dashboard TTFB 920 → 278 ms (schema v13).
• 2.1.25 — The WAF blocks the WordPress-core REST batch route-confusion attack class on every plan (structural rules, not token matching), inspects a decoded copy of the request body (closing an encoded-payload bypass), and Paranoia-Level-2/3 blocks render their specific reference category.
• 2.1.22 – 2.1.24 — Enforced 2FA defaults to forced enrolment instead of a lockout (admins and super admins can never be hard-locked out); a duplicate submit of the 2FA challenge no longer strands users on "session expired"; the PHPUnit eval-stdin.php RCE probe (CVE-2017-9841) is blocked on every plan.
• 2.1.14 – 2.1.20 — Production-hosting correctness: UTC-consistent datetimes (auto-blocking silently failed on non-UTC database servers), hidden login works behind page caches and on trailing-slash/nginx sites, Extended Protection auto-configures on nginx + PHP-FPM and skips body inspection for signed-in editors, API health uses a rolling window, and hot-path relay-quota polling was eliminated.
• 2.1.9 – 2.1.13 — Backend-managed WAF exceptions with a one-click "Allow" action (schema v10), self-explanatory block logging (matched value, target, method, URI, user-agent), MainWP provisioning can switch sites into Community mode, and the security dashboard became a full analytics view (seven threat families, WAF rule-group chart, top attackers).
• 2.1.0 – 2.1.8 — The firewall release: a server-delivered, Ed25519-signed Rule Delivery Framework feeding a request-inspecting Web Application Firewall (free engine + Paranoia-Level-1 baseline, PRO Level 2/3 via Priority Sync), verified-bot detection, disposable-email blocking, a comment honeypot, security response headers (basic free, advanced PRO), a dashboard protection & hardening score, block-page reference codes (X-RIP-Ref), the Business audit event trail (schema v9), MainWP integration and a Firewall admin area — followed by false-positive fixes for genuine crawlers and the fail-safe drop-in removal.
• 2.0.x — Network-wide multisite activation (Network: true), per-blog tier management, tier-upgrade banners, app-password & geo-anomaly monitors hardened, WooCommerce frontend 2FA opens to PRO+, coordinated-attack Hardening Mode, decoy-path detect-and-report.
• 1.5.2 — Cache-plugin compatibility on the 403 page; 2FA throttle graduates to real escalation block; init priority 1.
• 1.5.1 — Blocking-tab clarity (Report-only > Auto-blocking > duration strategy); fixed-length and ladder editors swap inline.
• 1.5.0 — Progressive block escalation (5 m → 7 d ladder); cookie-banner endpoints bypassed by default; 404/comment-spam defaults relaxed.
• 1.2.4 — API-queue "Retry" button now actually fires the API call.
• 1.2.0 — Seven new sensors: app-password monitor, REST-burst monitor, user-enumeration block, 404/scan detector, geo-anomaly, password strength, hide-login URL.
• 1.1.0 — Central mailer with brand template.
• 1.0.0 — Initial public release: IP blocking, 4-method 2FA, setup wizard, list tables.

Full history: CHANGELOG.md on GitHub.

Looking for the smaller edition?

Last updated: August 6, 2026 · Maintained by the ReportedIP team