16 WordPress Attack Detection Sensors

WordPress attack detection is only as good as the signals it watches. ReportedIP Hive runs 16 independent sensors across the login, comment, REST, XMLRPC and 404 surfaces — every one with a tunable threshold and a sane default.

This guide lists all 16 sensors, the default thresholds they ship with, and the attack each one stops.

What is ReportedIP Hive?

ReportedIP Hive is a complete WordPress security plugin that combines brute-force protection, a full 2FA suite and opt-in community threat intelligence. The detection layer described here is free in every mode, including fully offline Local Shield. The full ReportedIP Hive feature set lives on the product hub.

The 16 detection sensors and their defaults

Each sensor counts events per IP inside a rolling window. Cross the threshold and the IP graduates to the block ladder. Defaults are conservative on purpose — you can tighten or loosen every one under Settings → Protection.

Failed logins — 5 fails / 15 min.
Password spray — distinct usernames from one IP, 5 / 10 min. Counters are hashed, so no plaintext usernames are stored.
Comment spam — 5 / 60 min, evaluated before the comment filter runs.
XMLRPC abuse — 10 / 60 min, with system.multicall watched separately.
Application-password abuse — REST/XMLRPC Basic-Auth attempts that try to bypass 2FA, 5 / 15 min.
REST API rate-limit — global 240 / 5 min, sensitive routes 20 / 5 min.
User enumeration defence — blocks ?author=N, /wp-json/wp/v2/users and oEmbed lookups, and masks login errors.
404 / scanner detection — 12 / 2 min, plus an instant block on known-bad paths like .env, wp-config.bak and /.git/.
Web Application Firewall — inspects the URI, query string, body and user-agent against a signed, server-delivered ruleset (SQLi, XSS, path traversal, command injection, SSRF, Log4Shell and more). The engine and the OWASP-Top-10 baseline are free on every plan; the deeper Paranoia-Level-2/3 rulesets ride Priority Sync on Professional.
Verified bot detection — confirms Googlebot, Bingbot and other crawlers against their official IP ranges first, then a forward-confirmed reverse-DNS fallback. Spoofers are flagged or blocked; genuine crawlers are never blocked.
Disposable-email blocking — checks the address at registration (WordPress and WooCommerce) against the throwaway-mail list, with off / monitor / block modes. Privacy relays like Apple Hide My Email pass through by default.
Comment honeypot — 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.
Geographic anomaly — a login from a country never seen for that user, which can optionally revoke trusted-device cookies.
Password policy — minimum length, character classes and an optional Have-I-Been-Pwned k-anonymity check.
WooCommerce login hooks — checkout and my-account forms tracked separately from wp-login.php.
Cookie-banner consent endpoints — Real Cookie Banner, Complianz, Borlabs and CookieYes are whitelisted from the REST rate-limit by default.

Why search engines and AI crawlers do not trip them

Since 2.0.5, Googlebot, Bingbot, GPTBot, ClaudeBot, PerplexityBot and other verified crawlers are excluded from the 404 and REST burst triggers, so a legitimate crawl over stale URLs never lands a bot in the block ladder. The exception is deliberate: a request to a honeypot path like /.env still triggers instantly, even from a self-declared “Googlebot” — that request is the attack indicator.

How counting becomes a block

The brute-force-style sensors share one failure-counter ladder: 3 fails → 30 s, 5 → 5 min, 10 → 30 min, 15 → 1 h. After the 15th failure the IP is graduated to a real entry in the blocked table through the canonical handle_threshold_exceeded() pipeline, which then fires the progressive escalation ladder and, in Community mode, queues an anonymised report.