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

Quickstart

The quickstart replaced the ten-step setup wizard in 2.1.54. It asks two questions, mode and key, reads your plan from the key check and switches on a recommendation for that plan. Community Network is preselected and needs a checked key; Local Shield is the alternative and never blocked. The expert button applies the same recommendation and opens the settings; an existing JSON export can be imported instead. The old address page=reportedip-hive-wizard redirects to the quickstart.

A plan upgrade later switches on what the new plan recommends for every setting you have not changed yourself; the post-upgrade banner lists what changed. Re-running the quickstart re-applies the recommended values for your plan and the three switches; every other setting stays as it is.

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 Protection → Detection & Thresholds. The table also carries three companion mechanisms that ride the same pipeline without counting as sensors of their own: the decoy paths report to the community instead of blocking locally and belong to the honeypot layer, the hidden login URL is an access switch rather than a detector, and block escalation is the response ladder every sensor feeds into. The plugin itself counts sixteen sensors, and so does its readme.

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 Protection → Blocking & Escalation → Progressive blocking. The quickstart's Balanced recommendation leaves the ladder on, 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 reportedip.com: versioned, Ed25519-signed and staggered by tier across several rule sets. 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 lives on the Protection page, in the Firewall & Bots card (engine, mode, Paranoia-Level selector, bot verification, spam defence). Rule sync, WAF exceptions, the Extended Protection guard and every web-server snippet sit on the Tools page (Rules and Server tabs; listed in the menu in expert mode, always reachable by URL). The firewall log is on the Activity page.

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. Tools → Rules → 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 Spam

• 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. Since 2.1.52 a bot that walks into the trap also counts towards the per-address comment counter, so a repeat offender reaches the block threshold.
• Comment spam filter (free, since 2.1.52). Scores every incoming comment on link count, link density, the number of distinct domains, throwaway mail domains, giveaway top-level domains, a domain in the author name and a body that carries no message behind a link. Since 2.1.58 it also reads the user-agent header, link markup pasted back from a rendered page, digits and foreign script in the author name, the language of the text against the language of the site, a praise opening next to a link, how often a link target has been submitted before, and whether the same text has arrived already. Measured against 27,796 real comments of a site collecting them since 2014, that lifts the hit rate from 9 to 95 per cent while the false positives fall to none. Several signals have to agree before a comment counts. The default action files it as spam for review, rejecting it outright is opt-in, and the filter can be switched off under Protection → Registration & Spam.
• Form execution proof (free, since 2.1.53). The comment, sign-up and password-reset forms carry a hidden anchor field, and a small script adds a second field whose name is random per installation. A submission carrying neither has never rendered the form, which is what a script posting straight at the address looks like. Nothing request-specific is emitted, so page caches are unaffected. For comments the result is a scoring signal, so a visitor browsing without JavaScript has their comment filed for review rather than refused, and that reason on its own never counts towards a block; sign-up and password reset do refuse and explain why. REPORTEDIP_HIVE_DISABLE_FORM_PROOF in wp-config.php switches the whole layer off.
• Form protection on other form plugins (Professional, since 2.1.58). The same check on Contact Form 7 and on the Ultimate Member sign-in, sign-up and password forms, and with Business on Formidable Forms, Formidable Forms PRO and Elementor Forms. One switch per plugin, and for 24 hours after a switch goes on a submission that never carried the proof is still accepted, so a page from an older cache locks nobody out. An Ultimate Member sign-up also runs through the registration rules: the plugin writes the account itself instead of going through the WordPress sign-up, so without this a throwaway address or a reserved name would only be caught moments before the row is written and with WordPress's own wording.
• Computation check on forms (Professional, since 2.1.58). The proof field above has a name that is readable in the page, so a script that loads the form once can post that field back and pass for a browser. With this switched on the field has to carry a worked-out answer instead. The server plants a starting value, the browser spends a few milliseconds on it in the background, and the server checks the answer and refuses a second use of the same one. The visitor sees nothing and never has to read a distorted image, and no third-party service gets to see them. Starting values stay valid long enough that full-page caches keep working. It needs HTTPS, because the browser hash function only exists on a secure connection; without it no sum is handed out at all and everything behaves exactly as before. A visitor with JavaScript switched off is treated exactly as they are today, no better and no worse. The difficulty rises on its own while the hardening mode is active. Switch it on under Protection → Registration & Spam.
• Your own forms can use it too. A contact form, a booking form or any plugin form can take the same check instead of a CAPTCHA: add the surface to the reportedip_hive_form_proof_adapters filter, call ReportedIP_Hive_Form_Proof::field( 'my_form' ) where the form renders and ReportedIP_Hive_Form_Proof::passes( 'my_form' ) where it validates. Ready-made adapters for the large form plugins are planned.

Tor Exit-Node Blocking (Professional)

Since 2.1.41 Hive can reject connections from known Tor exit nodes. The feature is strictly opt-in, the toggle lives under Protection → Blocking & Escalation and is off by default, and requires a Professional plan: the exit-node list arrives as a signed tor_exits ruleset through the regular rule sync and is refreshed twice a day server-side, so it stays current as exit nodes rotate. The community isTor reputation flag covers addresses the list has not caught up with yet.

Tor blocks are deliberately mild. They are temporary: 24 hours by default, adjustable via the reportedip_hive_tor_block_hours filter, and they are never reported to the community, because operating a Tor exit node is not abuse evidence. Whitelisted IPs are never Tor-blocked. Once a block expires, the next request re-evaluates the current exit-node list.

Registration Rules

Since 2.1.51 every sign-up surface runs through one rule set: the WordPress registration form, the WooCommerce customer registration, Multisite sign-ups and programmatic user creation. The cards live under Protection → Registration & Spam and are evaluated in a fixed order, first hit wins: IP allowlist, rate limit, prohibited username, e-mail rules, throwaway-mail check.

• Prohibited usernames. One entry per line on top of a built-in baseline (admin, administrator, root, sysadmin, superadmin, webmaster, hostmaster, postmaster, support, moderator), which can be switched off and never counts against the free limit.
• E-mail rules. One list with three modes: off, block the listed addresses, or allow only the listed addresses. A bare host name means *@host. An allow-mode hit overrides the throwaway-mail check; an empty list in allow mode behaves as off, so nobody locks themselves out.
• Registration rate limit. Per IP address, three sign-ups per 60 minutes by default, free and configurable (window 1 to 60 minutes). It only refuses the registration: no IP block, no community report, so a NAT office is never punished for its neighbours.
• Allowlist-only registration (Professional). With IP ranges in the list, only those ranges may create an account.
• Unknown-username block (opt-in, off by default). A sign-in attempt against a username that does not exist blocks the IP immediately. Note the trade-off: the resulting block is an existence oracle for user names, which is why the switch is off by default and the event is never reported to the community.

Entry grammar. A plain entry matches exactly (case-insensitive), an entry containing * is an anchored wildcard, and an entry wrapped in slashes (/^shop[0-9]+$/) is a regular expression. Free plans get ten plain entries per list, wildcards included; Professional removes the limit and enables regular expressions and allowlist-only registration. A save that exceeds the free limit is rejected with a plan notice rather than silently truncated.

Refusals are logged as prohibited_username, registration_denied and registration_limit and can be filtered on the Activity page under Registration.

Access Lockdown Switches

Also since 2.1.51, and free on every plan: switches under Protection → Security Headers that turn off parts of WordPress a site does not use. All of them are off by default and reversible on the same screen.

• REST API access. Three modes: open, signed-in visitors only, or restricted to selected roles. Namespaces on the allowlist stay public in every mode, seeded with the endpoints that break otherwise (oembed/1.0, wp-site-health/v1, the common cookie-banner and form namespaces, the WooCommerce Store API); reportedip-hive/v1 is always allowed so the 2FA routes keep working. Guests get 401, signed-in users outside the role list get 403. Closing the API for guests removes the REST discovery links as well.
• XML-RPC. Refuses xmlrpc.php, disables pingbacks, drops the X-Pingback header at the source and removes the RSD and WLW manifest links. Application passwords over REST are unaffected, which is the modern replacement for XML-RPC clients.
• Feeds. RSS, Atom and comment feeds answer 404 and the feed links disappear from the page head.
• Admin area for signed-out visitors. Refuses /wp-admin/ for visitors who are not signed in, and with it the /admin and /dashboard aliases, which WordPress redirects there. The /login alias still reaches the login form unless Hide Login is on: only Hide Login removes the core redirect that sends it to wp-login.php. Hide Login closes wp-admin for visitors as well; the switch makes that part available on its own. admin-ajax.php and admin-post.php stay reachable, because unauthenticated callbacks legitimately post there.
• PHP execution in uploads. Writes a marker block into the uploads .htaccess that denies requests to PHP-ish file names, including the classic double extension shell.php.jpg. Apache only; on nginx and unknown servers the page shows the snippet to paste into the server configuration instead. Switching it off removes the block completely.
• Software fingerprints. Removes the WordPress generator tag and switches PHP error display off, unless WP_DEBUG and WP_DEBUG_DISPLAY are on. This is cosmetic hardening: version numbers are still derivable from asset URLs.

The user sitemap (wp-sitemap-users-1.xml) is not a switch of its own. It disappears while Block user enumeration is on, which is the default, because it published exactly the list that defence hides.

Refusals are logged once per IP address and event with a five-second throttle (rest_denied, xmlrpc_denied, feed_denied, admin_guest_denied). They never trip the block ladder and are never reported to the community: this is access control, not attack detection.

System Readiness

Eighteen detectors watch the parts of an installation that fail quietly: twelve report a fault, six suggest an improvement and appear as next-step cards on the dashboard rather than as an issue. Open issues appear under System Status with their severity, when they first appeared, a link to the responsible setting and a link to this page. Critical and warning issues additionally raise one summary notice on the plugin pages, the dashboard widget shows the count, and wp reportedip status reports them in the issues field. Warnings and advisories can be dismissed site-wide for seven days; critical issues cannot be dismissed. An issue that disappears is forgotten and starts over if it returns.

• Guard queue not writable (critical). Extended Protection is on, but the pre-WordPress guard cannot write its hit queue, so its blocks are never imported and never escalate. Fix the permissions of the directory named in the message, or switch Extended Protection off.
• Scheduled tasks stalled (critical). Every Hive cron hook is more than 24 hours overdue, so queue processing, reputation sync and cleanup are all frozen. Usually a broken WP-Cron loopback; configure a real system cron and set DISABLE_WP_CRON.
• WP-Cron disabled without a replacement (warning). DISABLE_WP_CRON is set, ALTERNATE_WP_CRON is not, and no external trigger has run for over an hour.
• Trusted IP header without proxy ranges (warning). A client-IP header is honoured for every peer, so anyone reaching the origin directly can spoof an address, shed a block or impersonate a whitelisted IP. Declare your proxy ranges under Community.
• Database schema outdated (critical). The stored schema version is behind the plugin's. Usually a migration that aborted; reloading a plugin page retries it.
• Community layer degraded (warning). The recent request window shows a low success rate. Check outbound HTTPS to reportedip.com and the Community Access Key.
• Mail relay cap reached (warning). The monthly managed-mail allowance is used up and 2FA mails fall back to wp_mail(). Book a top-up bundle or wait for the reset.
• SMS relay cap reached (warning). The monthly SMS allowance is used up. Users with SMS as their only method should add a second method.
• Mail delivery failing (warning). WordPress reported repeated wp_mail_failed errors, so 2FA codes and alerts are not arriving. Check the SMTP configuration. Recipient addresses are stripped from the stored message.
• No encryption backend (critical). Neither libsodium nor OpenSSL is available, so TOTP secrets and phone numbers cannot be encrypted at rest. Ask your host to enable one of the two extensions.
• Report queue has failed entries (warning). Reports exhausted their retries. Inspect and retry them on the API Queue tab.
• Report queue backlog (warning). Pending reports are piling up, which normally points back at a cron or connectivity problem. Both queue checks stay silent in Local Shield and without a Community Access Key, where the backlog cannot be worked off at all (since 2.1.57).
• Login address still public (advisory). Hide Login is off, so every bot knows where the sign-in form is. The next-step card takes a slug and switches the feature on in one step.
• Storefront 2FA included but off (advisory). The site runs WooCommerce and the plan includes the themed customer challenge, which is not switched on. One click enables it.
• Footer badge off (advisory). The "Protected by ReportedIP" badge is not shown. It is optional, and one click switches it on.
• Extended Protection possible but not running (advisory). The server supports the pre-WordPress guard and it is not active, so every blocked request still boots WordPress first.
• Local Shield instead of the community network (advisory). The site protects itself but neither asks the network nor contributes to it.
• Your own second factor is missing (advisory). Two-factor authentication is on for the site and the account looking at the page has no method set up. Raised per person, never site-wide.

Trusted Proxy Sources (Cloudflare, Reverse Proxies, Load Balancers)

When your site runs behind Cloudflare, a reverse proxy or a load balancer, the connecting peer is the proxy, the real visitor address travels in an HTTP header such as CF-Connecting-IP or X-Forwarded-For. Select that header under Protection → Detection & Thresholds → Trusted IP Header, and since 2.1.41 declare the proxy's addresses in the Trusted Proxy Sources list right below it, one IP or CIDR range per line, e.g. the published Cloudflare ranges.

With the list in place, the header is only honored for requests that actually connect from a declared proxy address. Anyone reaching the origin directly cannot spoof the header to impersonate a whitelisted address or shed an active block. An empty list keeps the previous behavior (header accepted from any peer), so existing setups keep working, but if you trust a header, declare your proxies. The same check is enforced in the pre-WordPress Extended Protection guard.

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

Since 2.1.57 the dashboard answers “done, and now?”: a status banner names the plan the recommendation was applied for, the setup date and how many settings deviate from it; next-step cards (Hide Login off, storefront 2FA included but off, badge off, Extended Protection possible but not running, Local Shield instead of the community network, your own second factor missing) each carry an inline action or a link and can be snoozed for seven days; a row per protection area shows the short status and jumps to the card; and at most one plan card renders per visit. Expert mode is a switch in the page header.

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).

Since 2.1.41 the headline numbers also surface as a security widget on the WordPress dashboard itself, attacks blocked over the last 30 days, blocks today, active IP blocks, protection layers and the detection score appear right on wp-admin's front page, with deep links into the plugin. On multisite the widget renders on the network dashboard and, for super admins, on sub-site dashboards with network-wide numbers. Since 2.1.51 it also carries the number of open readiness issues, see System Readiness.

Alongside the dashboard there are seven list-table screens: Blocked IPs, Whitelist, Security Logs, API Queue, the audit event trail (Business), the session manager under Users → Sessions (Business) and the 2FA admin grid. A separate System Status page lists every open readiness issue with its severity, when it first appeared and a jump to the setting responsible. Since 2.1.62 the event filter of the security log can be searched and selects whole groups, and every event type the plugin writes is in one registry.

Audit Event Trail (Business)

Since 2.1.62 the trail records who changed what on the site, not only what happened to accounts. Eight trigger groups, 48 event types, each group a switch on the Protection page (Privacy and Logs card):

• Sign-ins and sign-outs (off by default: the loudest rows, and failed attempts are in the security log anyway).
• User accounts: registration, deletion, profile, e-mail and password changes, role changes with the acting user, password resets, account blocks, ended sessions, edited role capabilities.
• Pages and posts: published, unpublished, trashed, restored, deleted, URL slug changed. Autosaves, revisions and auto-drafts are ignored.
• Plugins, themes and core: installed, updated, activated, deactivated, deleted, theme switched, core updated, with the version before and after. Automatic updates are rows too, marked as cron.
• Site settings: 26 core options (site address, permalinks, reading, discussion, registration, automatic updates) and every Hive setting, each with the old and the new value; a list is stored as what was added and removed.
• Menus and widgets: menus created, changed and deleted, menu locations, widgets added to or removed from a sidebar.
• Theme and plugin file editor: a file saved through the built-in editor, recorded only when the file actually changed.
• Network (Multisite only): sites created, changed, archived or deleted, users added to or removed from a site, super admin granted or revoked.

Every row names the acting user, how the request came in (browser, WP-CLI, cron, REST, AJAX) and the affected object with a link while it exists. Secrets are never written: a data key or option name that names a password, token, key or code keeps its values out. Retention defaults to 90 days, adjustable from 1 to 365, and the nightly sweep runs in 5,000-row chunks like the security log. Stored in the dedicated audit_log table; the GDPR exporter and eraser cover it.

The tab under Activity filters by event or trigger group, user, address, object and date range, and the CSV and JSON exports carry the active filter. On a network the Network Admin narrows the list to one site or to the network rows, and every site administrator has an Audit Trail page under the site menu with that site's rows. Below Business the tab shows five sample rows and what it would answer; nothing is recorded there, and the 30-day security log stays on every plan.

User Account Control and Sessions (Business)

Since 2.1.51 an account can be blocked without deleting it: from the user's profile page, from the Users list (column, "Blocked" view and bulk actions) or with wp reportedip user block. The block carries an optional message shown at sign-in and an internal note that is never shown to the user.

A blocked account keeps all of its content but cannot sign in, cannot authenticate an application password and cannot complete a password reset. Blocking drops every session and every trusted 2FA device immediately, so an already signed-in user is out on the next request. Blocking yourself or a super-admin is refused, and on a single-site install so is blocking the last remaining administrator. A block stays enforced even if the plan expires, and lifting a block is never gated.

Users → Sessions lists the active sessions of every signed-in user with 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 the list. Blocks and terminations are recorded in the audit event trail. On Multisite the page lives in the network admin, and a block applies network-wide because WordPress users and sessions are network-global.

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.

Since 2.1.47 the MainWP extension can additionally manage Hive settings centrally: it reads a versioned settings schema from each site, applies a global policy with per-site field overrides, and detects drift through a settings fingerprint every sync reports. Validation always happens on the managed site itself, per key, with plan-gated values skipped gracefully.

Cloud Fleet Management (Business)

On the Business plan the same settings policies can be managed without MainWP, directly from your reportedip.com dashboard under Domains: define one global policy, override single fields per site, push with one click and see immediately when a site drifts away from the policy, including a live target/actual comparison per site.

• Strictly opt-in. Each site decides: the "Cloud fleet management" toggle on Hive's General settings tab is off by default. Without it, the site rejects every management request.
• Signed requests only. Every push is Ed25519-signed by the reportedip.com fleet service and verified on your site against a public key bundled in the plugin, plus a five-minute freshness window, single-use request ids, a binding to your site's own address and a proof of your Community Access Key. There is no password, token or extra credential to manage.
• Same rules as MainWP. Both dashboards speak the identical settings protocol; every value is validated on your site before it is written, and plan-gated settings are skipped, never forced.
• Requires Hive 2.1.48 or newer, Community Network mode and a Business (or Enterprise) plan.

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, an all-sites Logs view and the audit trail with a site filter.
• Site Admins on a sub-site get a read-only Status / Logs UI, the audit trail of their own site (Business) and 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.

Adaptive Step-Up Triggers (Professional)

Enforcing 2FA for a role asks for the second factor at every sign-in. Adaptive triggers, added in 2.1.51, are the middle ground for everyone else: users who have set up a method are asked again only when something about the sign-in has changed. The matrix lives under Protection → Two-Factor Authentication → Enforced roles, one column per trigger, one row per role.

• New country, new IP address, new network (the /24 or IPv6 /64) or new device, each compared with that user's own history. Country detection needs Community Network mode; in Local Shield that one trigger stays inert.
• Every N days since the last passed challenge and every N sign-ins, with N configurable next to the matrix.
• More than N concurrent sessions for that user.

A triggered challenge ignores the trusted-device cookie, which is the entire point: the device is trusted, the circumstances are not. The 2FA IP allowlist and the reportedip_2fa_bypass filter still bypass. Users who have no method configured are never locked out; the skip is logged (2fa_stepup_skipped_no_method) and they are reminded to set one up. The history is per user, so the first sign-in after switching a trigger on never challenges, and the administrator role can only be armed once an administrator has passed one challenge on the site.

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 Protection → Two-Factor Authentication → 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 quickstart and 2FA pages.

Configuration Overview

All settings live on one page, ReportedIP Hive → Protection: fourteen cards, one per area, each with a short status, a search box that opens the matching card, and two depths. Simple shows the sixteen settings that matter day to day; the expert switch in the page header shows every field. What is not a setting (the Extended Protection drop-in, server snippets, rule sync, exceptions, import/export, test mail) sits on Tools, listed in expert mode and always reachable by URL. Every option sits in a single canonical registry, carries a one-sentence description and is sanitised in one place, so the Protection page, the MainWP form and the cloud fleet show the same field with the same text, and the quickstart writes through the same registry. Every registry option can be managed remotely. Only a handful stay local by design: the connection identity (operating mode, API key, endpoint), the remote-management opt-in itself, the uninstall data switch, the hardening master toggle (its "no stored value" state is what turns hardening on automatically from Professional upwards) and the Extended Protection switch, which needs a server directive next to it.

The most important defaults:

Database Tables

Nine tables, created on activation and prefixed wp_reportedip_hive_. Schema version 17, with idempotent step-by-step migration on every plugin update; opt-in delete on uninstall. Migration v16 shipped with 2.1.50 and lifts reputation block thresholds that were stored below the 25 % floor, so the settings screen shows what is actually enforced. On Multisite every table lives under $wpdb->base_prefix so threat decisions apply network-wide. Migration v17 shipped with 2.1.62 and adds the object columns of the audit trail.

• 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; race-safe atomic upsert on a unique (IP, attempt type) key since schema v15.
• 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 audit trail of who changed what (Business); added in schema v9, object columns since schema v17.
• 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 the quickstart switches on uses the same component with a configurable variant and alignment.

Since 2.1.57 the Community page carries a Badges tab: the footer badge with a live preview on top, and below it a banner builder. Pick one of six templates (footer badge, shield, threat counter, community banner, contributor, login shield), adjust variant, number, wording, theme and alignment, and copy the generated shortcode. Colours, text overrides and the full attribute list sit behind a disclosure.

WP-CLI Reference

The 2FA tooling, the hardening mode and (since 2.1.41) the community IP lookup are fully scriptable:

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
wp reportedip hardening <status|activate|deactivate>
wp reportedip lookup <ip> [--format=<table|json|csv|yaml>]
wp reportedip status [--format=<table|json|csv|yaml>]
wp reportedip user block <user> [--message=<text>] [--note=<text>]
wp reportedip user unblock <user>
wp reportedip user list [--format=<table|json|csv|yaml>]

wp reportedip status reports the operating mode, the plan and, since 2.1.51, an issues field listing the open readiness issues as key (severity), which makes it usable as a monitoring probe. The user commands need a Business plan for blocking; unblocking always works.

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).
• apply_filters('reportedip_hive_blocked_page_strings', $strings, $context) override the visitor-facing texts on the 403 block page (white-label; keys doc_title, title, message, reason). Since 2.1.41.
• apply_filters('reportedip_hive_reputation_block_hours', 24) / apply_filters('reportedip_hive_tor_block_hours', 24) duration of the temporary reputation and Tor exit-node blocks.
• do_action('reportedip_hive_threshold_exceeded', $ip, $event_type, $details) fired on every confirmed sensor detection, regardless of the auto-block and reporting settings. Since 2.1.41.
• do_action('reportedip_hive_ip_blocked', $ip, $reason, $blocked_until) fired when an IP is blocked; $blocked_until is a UTC datetime or null for permanent.
• do_action('reportedip_hive_ip_unblocked', $ip) fired when a block is lifted.
• do_action('reportedip_hive_report_queued', $ip, $category_ids, $report_type) fired once per report that enters the API queue (comma-separated category IDs; negative or positive).
• do_action('reportedip_hive_access_denied', $ip, $context) fired just before the 403 block page renders. Since 2.1.41.
• do_action('reportedip_hive_2fa_verified', $user_id, $method) fired after a passed two-factor challenge, on the login form and on the REST verify endpoint alike. Since 2.1.51 the core wp_login action fires there as well: until then it only fired for logins that never saw a challenge, which left the geo-anomaly sensor, the new-device mail, the audit trail and the 2FA reminder blind to every challenged sign-in.
• apply_filters('reportedip_hive_reputation_threshold_floor', 25) raise the 25 % floor under the community-confidence block threshold. Lowering it is not possible.
• apply_filters('reportedip_hive_2fa_bypass', false, $user) skip the second factor for a user, honoured by the adaptive step-up triggers as well.

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).

The user sitemap is gone after the update

wp-sitemap-users-1.xml no longer exists once user-enumeration blocking is active, and that option is on by default, so most sites lose it with 2.1.51. That is deliberate: the same defence already blocks ?author= and the REST user route, and the sitemap was the last published list of usernames on the site. Search engines do not need it, author archive pages stay crawlable if you keep them public (Protection → Detection). If you really need the file back, turn user-enumeration blocking off and accept that the usernames are public again.

A plugin, app or feed stopped working after a lockdown switch

Open Protection → Security Headers and turn the suspect switch off again; the change is immediate. Typical cases: a mobile app or a Jetpack-style service that still speaks XML-RPC, a headless front end or a block-editor plugin that calls the REST API without being signed in (add its namespace to the allowlist instead of opening the API again), a podcast or newsletter service reading the RSS feed, and a payment provider posting into /wp-admin/. The Activity page lists every refusal with its path under Firewall, so you can identify the caller before changing anything. A registration that is refused unexpectedly is logged under Registration together with the rule that matched.

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.

Locked yourself out? (own IP blocked, wp-admin unreachable)

If your own IP landed in the block list and wp-admin is unreachable, you can restore access directly in the database, via phpMyAdmin or your host's database console. Prefer the admin UI (the whitelist form has an "Add my IP" helper since 2.1.41) whenever it is reachable; the direct database route is the emergency exit, not the everyday tool, because it bypasses the plugin's validation.

Add your current public IP to the whitelist table, whitelisted addresses win over every block:

INSERT INTO wp_reportedip_hive_whitelist (ip_address, ip_type, reason, added_by, is_active)
VALUES ('203.0.113.42', 'ipv4', 'Self-rescue: restore admin access', 1, 1);

Use 'ipv6' or 'cidr' as the ip_type for an IPv6 address or a range, for rotating residential IPv6 prefixes, whitelist your /64 network as 'cidr'. added_by is your WordPress user ID (1 for the first admin account). Alternatively, delete your row from the block table:

DELETE FROM wp_reportedip_hive_blocked WHERE ip_address = '203.0.113.42';

Replace the wp_ prefix with your actual table prefix from wp-config.php if it differs (on multisite the plugin tables use the base prefix). The change takes effect on the next request. If Extended Protection (the pre-WordPress guard) is active and the block persists, also delete the cached block-list file wp-content/uploads/reportedip-hive/blocked-*.list the guard is fail-open and the file is rebuilt automatically on the next sync.

The firewall blocks a legitimate request (WAF false positive)

Open Activity, 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 Tools → Server 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: Attacker IP, threat category and timestamp are shared, and each request identifies the installation itself (site address, plugin/WordPress version, used for licence domain counting and support). 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 visitor tracking: No cookies, no tracking pixels. The only telemetry is the installation identity (site address, plugin/WordPress version) sent with Community-mode API requests, data about your installation, never about your visitors.
• 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 (Protection → Privacy & Logs) 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.62: The audit trail records who changed what: eight trigger groups (accounts, pages and posts, plugins and themes, settings with old and new value, menus and widgets, the file editor, the network) with the acting user, the request agent and the affected object, switches per group, 90-day default retention with a chunked sweep, a site filter for networks and an Audit Trail page for every site administrator. Every event type lives in one registry; the event log filter can be searched and selects whole groups, and form spam is back in the charts.
• 2.1.58–2.1.61: The form execution proof can demand a computation (Professional), a captcha replacement your own forms can use through a small API; Contact Form 7 and Ultimate Member are covered on Professional, Formidable Forms and Elementor Forms on Business; the comment spam filter reads eight more signals; the form settings got a card of their own and every setting names the plan it belongs to.
• 2.1.57: The Activity page opens on the event log behind a bookmarkable filter bar, the Community page splits into Settings, Community and Badges (one-click footer badge plus banner builder), the dashboard carries one status line and collapsed protection areas, and the report-queue readiness issues stay quiet while nothing can send them. A rejected access key no longer counts as a failed sample in the API health window.
• 2.1.56: The Settings and Firewall pages were replaced by one Protection page (a card per registry area, search, simple and expert depth, one apply service shared with MainWP, the fleet and the import) and a Tools page for the drop-in, rule sync, WAF exceptions, import, export, reset and the test mail. The dashboard gained a status banner, next-step cards from six advisory readiness detectors and a row per protection area. Old settings and firewall addresses redirect.
• 2.1.54–2.1.55: The setup wizard became a one-page quickstart that reads the plan from the key check and applies a plan-aware recommendation through the settings registry; a later plan upgrade switches on what the new plan recommends for untouched values. Every stored setting now follows one standard, and the dashboard shows the latest news from reportedip.com in the admin's language.
• 2.1.52–2.1.53: Comment and form defence. A scored comment spam filter of around twenty signals (a comment waiting for moderation is no longer a spam verdict), a cache-safe form execution proof on comment, sign-up and password-reset forms, and the community threat check extended from the sign-in page to those same three forms. Free on every plan.
• 2.1.51: Five new protections. Registration defence (prohibited usernames, e-mail rules, a per-IP sign-up rate limit, an opt-in block for sign-ins against usernames that do not exist), access lockdown switches for REST, XML-RPC, feeds, wp-admin, PHP in uploads and version fingerprints, and a system readiness register with twelve detectors, all free on every plan. Blocking an account plus the session manager under Users → Sessions on Business, adaptive two-factor step-up triggers per role on Professional. Seventy options moved into the settings registry (169 in total, all described, 71 remotely manageable), settings import can no longer bypass the sanitiser, and hardening mode now clamps thresholds on the WooCommerce and application-password login surfaces as well.
• 2.1.48–2.1.50: Cloud Fleet Management (Business) over three Ed25519-signed REST routes with a freshness window, single-use request IDs and audience binding, opt-in and off by default. A 25 % floor under the community-confidence block threshold with migration v16 lifting stored sub-floor values, and full IP management on WP-CLI (whitelist, block, unblock, blocked list, attempts reset) alongside wp reportedip status.
• 2.1.42–2.1.47: The security and correctness audit: admin-ajax.php brought inside the block gate and the firewall, single-use TOTP codes, a WAF exception that no longer masks the rules behind it, percent-encoded probes matched by three more sensors, and forty-two AJAX handlers on one shared permission guard. Plus a wp.org-style installation identity on every API request, a licensed-domains card on the dashboard, the canonical settings registry with its versioned remote protocol, and plugin updates visible to MainWP and ManageWP again.
• 2.1.37–2.1.41: Opt-in Tor exit-node blocking (Professional, signed tor_exits ruleset), trusted-proxy source ranges against forwarded-header spoofing, a security widget on the wp-admin dashboard, a never-block veto for community-verified infrastructure, a richer IP lookup with wp reportedip lookup, stable integrator hooks (reportedip_hive_threshold_exceeded), race-safe attempt counters (schema v15), plus a stricter firewall: crawler exemptions require a verifiable signal, payload rule groups block on the first hit, release builds ship the bundled rulesets again, and four rules close the CVE-2026-64638 (XSS2Shell) login-screen chain. Domain moved to reportedip.com.
• 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: 20. September 2026 · Maintained by the ReportedIP team