ReportedIP Hive 2.1.66: One Rule for Every Protected Form
ReportedIP Hive 2.1.66 puts every protected form on one rule: a bot that fills the hidden decoy field is refused, blocked and reported on its first try, on all 10 form surfaces the plugin covers. It closes a run of four releases from 23 and 24 September 2026 that added Gravity Forms, WPForms and Forminator, bound the computation check to your own site and blocked comment spam on the first clear verdict.
Update from the WordPress admin or download the current ZIP from the Hive product page. How the form protection works is explained in the form honeypot guide; this post records what changed in these four versions.
What changed between Hive 2.1.62 and 2.1.66?
Four releases shipped within two days.
| Release | Date | Main change |
|---|---|---|
| 2.1.63 | 23 September 2026 | Gravity Forms adapter, Contact Form 7 on every plan, comment spam blocked on a clear verdict, double-encoded traversal caught by the firewall |
| 2.1.64 | 23 September 2026 | Computation check bound to a signed, single-use task from your own site |
| 2.1.65 | 24 September 2026 | WPForms adapter, Elementor mail leak fixed, Ultimate Member sign-ups fixed |
| 2.1.66 | 24 September 2026 | Forminator adapter, one rule for every form, first-try block for a filled decoy field |
Which forms does Hive protect since 2.1.66?
Three adapters arrived in three releases: Gravity Forms with 2.1.63, WPForms and WPForms Lite with 2.1.65, Forminator with 2.1.66. Together with the adapters that were already there, Hive now protects 7 form plugins plus the comment, sign-up and password-reset forms of WordPress itself, 10 surfaces in all.
| Forms | Protected since | Plan |
|---|---|---|
| Comment form, sign-up and password reset | 2.1.53 | Every plan |
| Contact Form 7 | 2.1.58 | Every plan |
| Formidable Forms and Formidable Forms PRO | 2.1.58 | Business |
| Elementor Forms | 2.1.58 | Business |
| Ultimate Member | 2.1.61 | Business |
| Gravity Forms | 2.1.63 | Business |
| WPForms and WPForms Lite | 2.1.65 | Business |
| Forminator | 2.1.66 | Business |
2.1.63 also moved the plan line. Contact Form 7, the most common contact form, went from Professional to every plan, including Free, and the quickstart switches it on wherever the plugin is installed. Ultimate Member moved from Professional to Business, next to the other advanced adapters. A Professional site that already had the Ultimate Member switch on keeps the stored value and can still switch it off; the adapter stands down until the plan covers it again. The computation check on top of the proof needs Professional or above.
Each adapter has its own switch under ReportedIP Hive > Protection, card Form Protection. What happens on each plugin is covered in the guides for Gravity Forms and WPForms and Forminator.
What does one rule for every form mean?
Before 2.1.66 the forms disagreed about the clearest evidence the layer produces. A filled decoy field, the invisible input no person can see, has no innocent explanation. The third-party adapters refused such a submission, while the WordPress sign-up form and the password reset let it through. Since 2.1.66 one shared decision serves every surface: the same verdict leads to the same consequence, the same message and the same log entry.
A form bot is blocked and reported on its first try
Filling a hidden field takes a machine, so waiting for further attempts only gave the sender free runs. A filled decoy now goes straight to the block ladder and, in Community Network mode, into the community report, as on the comment form since 2.1.63. The report names the form the submission came through instead of a generic “suspicious activity”.
No refused submission disappears silently
Every adapter follows the same consequence rule: a refused sender sees a message at the form. Hive never files a submission in the form plugin’s spam folder and never drops it without a word, because nobody reads a spam folder and a wrong verdict would go unnoticed. A visitor whose browser did not run the script is refused with a message that says why, and that address is never counted towards a block. Since 2.1.67 the comment form refuses such a submission the same way.
A whitelisted address is never blocked by a fast sensor
Until 2.1.66 the whitelist was checked while attempts were counted, not when a sensor acted at once. The comment filter and the form layer both act at once, so a whitelisted address could still be blocked. The whitelist check now sits in the step every sensor passes before a block.
Why is the computation check bound to your own site?
Before 2.1.64 the computation check planted its task in the page. A script that fetched the page once could read the field names and the task and solve it in milliseconds. Since 2.1.64 the browser fetches the task from your own site instead: signed, valid for a short time, accepted once and harder when one network asks for many tasks. The page stays identical for every visitor, so full-page caches such as WP Rocket, LiteSpeed or a CDN keep working.
The check is built so that no real visitor loses a message:
- Every refusal is shown to the sender at the form.
- If the site cannot issue a task, or the check itself fails, the submission passes.
- A plugin update starts a new grace period and clears the page cache, so pages cached by the old version keep working.
- A visitor who clicks send before the task has arrived is held for a moment and then sent on.
- The task is not tied to the visitor’s address, so a phone that changes networks is not refused.
- The script opts out of Cloudflare Rocket Loader and of script combining in WP Rocket.
The computation check needs Professional or above. Sites without HTTPS keep the signed, single-use task without the arithmetic.
Which bugs did the four releases fix?
- A refused Elementor submission still sent the form mail. Since 2.1.65 the refusal stops the submission before any Elementor action runs, the mail included.
- Ultimate Member sign-ups failed the computation check. The proof script missed the way Ultimate Member sends its forms, so a fast visitor was refused. Fixed in 2.1.65.
- A form loaded later could never pass. Forms in popups or forms rendered again after a failed validation found no answer waiting. Since 2.1.63 the script prepares every fresh form again.
- The Extended Protection card was missing on PHP-FPM. The dashboard suggestion Switch on Extended Protection never showed on nginx and most managed hosts. Since 2.1.65 it uses the same detection as the Server tab.
- A refused contact form talked about a password reset. Since 2.1.63 every form gets its own wording.
- Three German strings showed garbled umlauts on the Protection page. Fixed in 2.1.63.
How does Hive block comment spam since 2.1.63?
The comment filter had detected and filed spam since 2.1.52, but blocking depended on a frequency counter that most spammers never reached. Measured over 13 days on a live magazine, 104 of 109 spamming addresses could never reach it, because they posted once or spread their comments over hours. Since 2.1.63 a clear verdict no longer waits for a second comment: a filled decoy field, or a spam score backed by signals a human reader does not produce, blocks and reports the address on the spot.
Comments that look suspicious only on soft signals still go through the counter, so a regular reader who links their own site is at most filed for review. The counter’s default moved to a longer window in the same release. Installs still on the old default were moved on update; a value you set yourself was left alone.
Which firewall gap did 2.1.63 close?
The baseline rule against directory traversal did not recognise the double-encoded and overlong UTF-8 forms of ../. The double-encoded form is what CVE-2026-87902 relies on, fixed in WordPress 7.1.2: PHP decodes the request once, and WordPress decoded the page name a second time. Since 2.1.63 the rule matches every encoding in both firewall layers and stays quiet on harmless dots such as file..txt. Sites in Community Network mode received the rule with the next ruleset sync. The firewall guide explains both layers.
What changes for a managed fleet?
The remote settings schema gained two switches, one for WPForms and one for Forminator, both recommended from Business in the quickstart. Nothing was removed or changed in kind, so a fleet dashboard that has not reloaded the schema keeps working. One developer filter of the old hourly computation task was removed; it only affected sites that hooked it.
Questions about Hive 2.1.66
Which plan protects WPForms and Forminator in Hive?
WPForms and Forminator protection is part of the Business plan, together with Gravity Forms, Formidable Forms, Elementor Forms and Ultimate Member. Contact Form 7, the comment form, sign-up and password reset are protected on every plan, including Free. The computation check on top of the proof needs Professional or above.
Does a refused visitor lose their message?
A refused visitor always sees at the form why it was not sent, and can correct it and send again. Hive never moves a submission into a spam folder or drops it without a message. When your site cannot issue a task or the check fails, the submission passes, so a fault on your side never costs a real visitor their message.
What should I check after updating to 2.1.66?
Open the Form Protection card and switch on every installed form plugin your plan covers; on Business the quickstart recommends WPForms and Forminator. Then run the self-test under Tools > Diagnostics, visible in Expert mode, and check the Event Log for refused submissions during the first days after the update.
Read on
The Hive documentation covers bot detection and form spam and caching and compatibility. Earlier release posts cover Hive 2.1.62 with the audit trail and Hive 2.1.57 with the rebuilt admin.