Veröffentlichungen

ReportedIP Hive 2.1.66: Eine Regel für WPForms, Forminator und jedes andere Formular

24. September 2026 · Patrick Schlesinger

ReportedIP Hive 2.1.66 schließt eine Serie von vier Releases in zwei Tagen ab: Der Formularschutz erreicht WPForms, Forminator und Gravity Forms, die Berechnungsprüfung ist an Ihre eigene Website gebunden, und für jedes geschützte Formular gilt eine Regel: Ein ausgefülltes Köderfeld wird beim ersten Versuch abgewiesen, gesperrt und gemeldet, auf allen zehn Oberflächen, die das Plugin jetzt abdeckt. Dieselbe Serie behebt eine abgewiesene Elementor-Übermittlung, die ihre Mail trotzdem verschickte, eine Ultimate-Member-Registrierung, die das Prüfskript nie zu sehen bekam, und einen Kommentar-Spam-Zähler, den fast kein Spammer je erreichte.

Aktualisieren Sie im WordPress-Admin oder laden Sie das aktuelle ZIP von der Hive-Produktseite. Die Adapter für Drittanbieter-Formulare gehören zum Business-Tarif, Contact Form 7 ist in jedem Tarif enthalten; die Funktionsliste je Tarif steht auf der Dokumentationsseite des Hive-Plugins.

Was sich zwischen 2.1.62 und 2.1.66 geändert hat

Vier Releases erschienen am 23. und 24. September 2026. Das ist die Summe daraus.

Release	Datum	Wichtigste Änderung
2.1.63	23. Sep.	Gravity-Forms-Adapter, Contact Form 7 in jedem Tarif kostenlos, doppelt kodierte Directory Traversal wird von der Firewall erkannt, Kommentar-Spam wird nach einer Bewertung statt nach einem Zähler gesperrt
2.1.64	23. Sep.	Berechnungsprüfung an eine Aufgabe von Ihrer eigenen Website gebunden, signiert und einmal gültig; kein Besucher verliert daran eine Nachricht
2.1.65	24. Sep.	Adapter für WPForms und WPForms Lite, Mail-Leck bei Elementor behoben, jQuery-Submit von Ultimate Member wird erkannt, Karte „Extended Protection” unter PHP-FPM
2.1.66	24. Sep.	Forminator-Adapter, eine Regel für jedes Formular, Sperre und Meldung beim ersten Versuch bei ausgefülltem Köderfeld, Whitelist wird im Dispatcher geprüft

Der Formularschutz deckt jetzt sieben Formular-Plugins ab

Drei Adapter kamen in drei Releases. Gravity Forms mit 2.1.63, WPForms und WPForms Lite mit 2.1.65, Forminator mit 2.1.66. Jeder hat seinen eigenen Schalter auf der Seite „Schutz” unter „Formularschutz”, jeder wird über die Klasse des jeweiligen Plugins erkannt, und jeder weist einen Bot am Formular ab: ein Validierungsfehler, den der Absender über dem Formular liest, kein Eintrag, keine Mail, nichts landet in einem Spam-Ordner, in den niemand schaut. Zusammen mit Contact Form 7, Formidable Forms, Formidable Forms PRO, Elementor Forms und Ultimate Member bewertet die Schicht jetzt sieben Formular-Plugins plus Kommentar-, Registrierungs- und Passwort-Zurücksetzen-Formular von WordPress selbst, zehn Oberflächen insgesamt.

Formular-Plugin	Seit	Tarif	Wo die Bewertung landet
Contact Form 7	2.1.58	Jeder Tarif	Validierungs-Hook, Abweisung wird am Formular angezeigt
Formidable Forms und Formidable Forms PRO	2.1.58	Business	Validierungs-Hook, Abweisung wird am Formular angezeigt
Elementor Forms (Elementor PRO)	2.1.58	Business	Feldfehler seit 2.1.65, der jede Submit-Aktion stoppt, die Mail eingeschlossen
Ultimate Member	2.1.61	Business	Anmelde-, Registrierungs- und Passwortformulare; eine Registrierung durchläuft zusätzlich die Registrierungsregeln
Gravity Forms	2.1.63	Business	Validierungsfehler auf Formularebene, mehrseitige Formulare werden auf der letzten Seite bewertet, API-Übermittlungen nie
WPForms und WPForms Lite	2.1.65	Business	Header-Fehler im Verarbeitungs-Hook, nach der Feldvalidierung des Plugins
Forminator	2.1.66	Business	Fehlerliste der Übermittlung, bevor der Eintrag gebaut und bevor die Mail verschickt wird

2.1.63 hat auch die Tarifgrenze verschoben. Contact Form 7, das verbreitetste Kontaktformular, ist in jedem Tarif abgedeckt und wird vom Schnellstart überall eingeschaltet, wo das Plugin installiert ist; Ultimate Member ist von Professional nach Business gewandert, neben die anderen erweiterten Adapter. Eine Website auf Professional mit eingeschaltetem Ultimate-Member-Schalter behält den gespeicherten Wert und kann ihn weiterhin ausschalten; der Adapter setzt aus, bis der Tarif ihn wieder abdeckt. Der Gravity-Forms-Leitfaden und der Leitfaden zu WPForms und Forminator gehen die Adapter Hook für Hook durch.

Jedes geschützte Formular liest dieselbe Regel

Bis 2.1.66 waren sich die Oberflächen beim eindeutigsten Beweis uneinig, den diese Schicht liefert. Ein ausgefülltes Köderfeld, das unsichtbare Eingabefeld, das kein Mensch sehen kann, ist Automatisierung ohne harmlose Erklärung. Die sechs Drittanbieter-Adapter wiesen eine solche Übermittlung ab und zählten die Adresse. Das WordPress-Registrierungsformular und das Zurücksetzen des Passworts sahen nur eine der vier Bewertungen an und ließen einen Bot durch, der jedes Feld ausfüllte, das versteckte eingeschlossen. Die Entscheidung liegt jetzt an einer Stelle, ReportedIP_Hive_Form_Proof::consequence(), und jede Oberfläche ruft sie auf: Eine Registrierung mit ausgefülltem Köderfeld wird mit einem Satz abgewiesen, den der Absender liest, und die Adresse verbraucht dasselbe Budget, das ein Kommentar oder ein Kontaktformular gekostet hätte.

Für einen Besucher ohne JavaScript ändert sich nichts. Seine Übermittlung trägt ein leeres Köderfeld und kein Prüffeld, und das ist eine andere Bewertung: Auf einem Kontaktformular wird sie mit einer Meldung abgewiesen, die den Grund nennt, auf dem Kommentarformular kostet sie einen Moderationsschritt, und auf keinem von beiden zählt sie in Richtung einer Sperre.

Ein Formular-Bot wird beim ersten Versuch gesperrt und gemeldet

Ein verstecktes Feld auszufüllen erfordert eine Maschine, also verschaffte das Warten auf einen zweiten und dritten Versuch dem Absender nur zwei freie Durchläufe und ließ die Community ohne Meldung zurück. Ein ausgefülltes Köderfeld geht jetzt direkt auf die Sperrleiter und in die Community-Meldung, so wie der Kommentarfilter denselben Beweis seit 2.1.52 behandelt. Die Meldung nennt das Formular, über das die Übermittlung kam, statt „suspicious activity”, und ein Kommentar, der sicher Spam war, nennt die Signale, die den Absender verraten haben, statt „1 spam comments in 0 minutes”, einem Satz, der beim Zusammenbauen zusätzlich eine PHP-Notice auslöste.

Eine Adresse auf der Whitelist kann von einem schnellen Sensor nicht mehr gesperrt werden

Die Whitelist wurde beim Zählen der Versuche geprüft, nicht beim Handeln, sodass jeder Sensor, der sich sicher genug war, um sofort zu handeln, daran vorbeilief. Der Kommentarfilter und die Formularschicht sind beide so sicher. Die Abfrage sitzt jetzt im Dispatcher, in dem jeder Sensor am Ende landet, sodass eine Adresse auf Ihrer Erlaubnisliste nie von einer Prüfung gesperrt wird, die den Zähler überspringt.

Die Berechnungsprüfung ist an Ihre Website gebunden

Vor 2.1.64 legte die Berechnungsprüfung ihre Aufgabe in die Seite selbst, mit einem Startwert, der nur von der Stunde abhing. Ein Skript, das die Seite einmal abrief, kannte den Namen des Köderfelds, das Prüffeld und die Aufgabe und löste sie in wenigen Millisekunden. Der Browser holt die Aufgabe jetzt stattdessen vom eigenen Endpoint der Website: signiert mit dem Salt der Website, zehn Minuten gültig, einmal akzeptiert und umso schwerer, je schneller ein Netz nach Aufgaben fragt. Die Seite trägt nichts als die Adresse des Endpoints, für jeden Besucher identisch, sodass ein Full-Page-Cache, LiteSpeed, WP Rocket oder ein CDN sie unverändert weiter ausliefert; die Aufgabe reist in einem POST, den kein Cache speichert. Gegen dasselbe Skript verifiziert: abgewiesen ohne Aufgabe, abgewiesen mit verbrauchter Aufgabe, abgewiesen mit manipulierter Aufgabe, durchgelassen mit frischer Aufgabe, genau einmal. Die stündliche Aufgabe und ihr Filter reportedip_hive_form_proof_buckets sind weg.

Kein Besucher verliert daran eine Nachricht

• Jede Abweisung wird dem Absender von dem Formular mitgeteilt, über das sie kam.
• Eine Aufgabe, die der Server nicht ausstellen kann, wird mit Schwierigkeit null herausgegeben statt zurückgehalten, und ein Fehler im Prüfer antwortet mit „bestanden”.
• Ein Plugin-Update startet den Karenztag neu und leert den Seitencache, sodass eine von der Vorversion gecachte Seite weiter funktioniert.
• Ein Browser, der absendet, bevor seine Aufgabe zurück ist, wird höchstens acht Sekunden festgehalten und dann so weitergeschickt, wie der Besucher abgeschickt hat.
• Die Aufgabe ist nicht an die Adresse des Besuchers gebunden, sodass ein Telefon, das zwischen Seitenaufruf und Absenden das Netz wechselt, nicht abgewiesen wird.
• Ohne HTTPS trägt die Aufgabe keine Rechnung, behält aber Signatur, Ablauf und Einmalgültigkeit.
• Das Script-Tag trägt data-cfasync="false" für Cloudflares Rocket Loader und data-nowprocket für WP Rocket, und der Endpoint wird über das Schema der Seite abgerufen, sodass ein Proxy, der TLS terminiert, nicht an einer Mixed-Content-Sperre scheitert.

Drei Abweisungen, die nicht taten, was sie sagten

Eine abgewiesene Elementor-Übermittlung verschickte die Formular-Mail trotzdem. Der Adapter übergab seine Abweisung an Elementor PRO nur als Meldung, und der Handler führt jede Submit-Aktion aus, die Mail eingeschlossen, solange er keinen Feldfehler hält. Dem Absender wurde gesagt, das Formular sei gescheitert, nachdem die Mail schon draußen war. Seit 2.1.65 ist die Abweisung zusätzlich ein Feldfehler, der die Übermittlung stoppt, bevor irgendeine Aktion läuft; die Browser-Spezifikation prüft den Mail-Catcher in beide Richtungen, ein abgewiesener nackter POST verschickt nichts, ein echter Browser verschickt genau eine.

Registrierungen über Ultimate Member scheiterten an der Berechnungsprüfung. Ultimate Member schickt seine Formulare mit einem per jQuery ausgelösten Submit ab, der kein natives Submit-Event feuert, sodass das Prüfskript die Übermittlung nie sah und ein Besucher, der klickte, bevor die Aufgabe zurück war, als nicht nachgewiesen abgewiesen wurde. Das Skript hört jetzt auch auf per jQuery ausgelöste Submits und behandelt eine in der letzten Sekunde vorbereitete Übermittlung als dieselbe, weil Gravity Forms denselben jQuery-Submit direkt nach seinem eigenen Pre-Submission-Hook auslöst. Jeder Adapter hat jetzt eine Browser-Spezifikation mit verlangter Berechnung: Contact Form 7, Elementor, Formidable, Gravity Forms, WPForms und Ultimate Member.

Ein nach dem ersten Durchlauf geladenes Formular konnte nie bestehen. Das Prüfskript las die Challenge einmal, als die Seite bereit war; ein Formular, das später kam, in einem Popup oder nach einer gescheiterten Validierung neu gerendert, fand keine berechnete Antwort vor. Seit 2.1.63 liest das Skript die Challenge neu und startet die Uhr neu, sobald ein Formular-Plugin ein frisches Rendern meldet, und seit 2.1.64 wird ein Submit ohne Antwort im Vorrat festgehalten, während eine geholt wird.

Kommentar-Spam wird nach einer Bewertung gesperrt, nicht nach einem Zähler

Der Kommentarfilter erkannte und sortierte Spam seit 2.1.52, aber die Konsequenz hing vollständig an einem Häufigkeitszähler: fünf abgelehnte Kommentare von einer Adresse innerhalb von sechzig Minuten. Über dreizehn Tage auf einem laufenden Magazin gemessen, schrieben 56 Prozent der spammenden Adressen genau einen Kommentar und der Rest verteilte seine über Stunden, sodass 104 von 109 Adressen die Schwelle nie erreichen konnten, egal wie offensichtlich der Spam war. Seit 2.1.63 wartet eine Bewertung, die für sich steht, nicht mehr auf einen zweiten Kommentar: Ein ausgefülltes Köderfeld oder ein Score bei oder über CERTAIN mit mindestens einem Grund, den ein Leser nicht erzeugen kann (kein Browser-User-Agent, eingefügtes Link-Markup, ein von Hand getippter Anker, eine Wegwerf-TLD, eine URL als Autorname, ein schon gesehener Text), sperrt und meldet die Adresse auf der Stelle. Scores, die nur aus weichen Signalen bestehen, laufen weiter durch den Zähler, sodass jemand, der ohne JavaScript surft und seine eigene Website verlinkt, weiterhin nur zur Durchsicht abgelegt wird.

Der Zähler selbst steht jetzt bei drei abgelehnten Kommentaren pro Tag, vorher fünf pro Stunde. Fünf innerhalb von sechzig Minuten ist ein Schub, den fast kein Spammer produziert, weshalb der Zähler ihn kaum je erreichte, und die Versuchstabelle setzte nach sechzig Minuten Leerlauf ohnehin neu an, sodass ein längeres Fenster in den Einstellungen nie mehr als den neu gestarteten Stand sah. Schema-Migration v18 hebt Installationen, die noch das alte Paar tragen, auf das neue; ein Wert, den ein Betreiber selbst gesetzt hat, bleibt unangetastet. Dasselbe Paar gilt für die Formular-Adapter.

Doppelt kodierte Directory Traversal kommt nicht mehr durch die Firewall

Die Traversal-Regel des Basis-Regelwerks kannte ../, ..%2f und %2e%2e/, aber nicht %2e%2e%2f mit kodiertem Schrägstrich, nicht das doppelt kodierte %252e%252e%252f und nicht die überlange UTF-8-Form. Die doppelt kodierte Form ist genau das, worum es beim Template-Resolution-Fix von WordPress 7.1.2 (CVE-2026-87902) geht: PHP dekodiert die Query einmal, WordPress dekodierte pagename ein zweites Mal, also schickt der Angreifer die doppelt kodierte Form, und die Firewall sah nichts, was sie kannte. Seit 2.1.63 trifft die Regel jede Kodierung auf der Leitung, in beiden Firewall-Schichten, und bleibt still bei file..txt oder per_page=2..5. Websites im Community-Network-Modus erhalten dieselbe Regel mit dem nächsten Regelwerk-Sync.

Kleinere Korrekturen, die auf einer echten Installation zählen

• Die Karte „Extended Protection einschalten” erschien auf PHP-FPM-Websites nie. Das Dashboard fragte, ob der Server .htaccess liest, aber die Ein-Klick-Einrichtung schreibt unter PHP-FPM, CGI und LiteSpeed eine .user.ini, sodass nginx und die meisten Managed-Hoster den Vorschlag nie bekamen. Die Karte folgt derselben Erkennung wie der Tab „Server”.
• Die Off-Screen-Regel des Köderfelds gewinnt gegen den Element-Reset eines Formular-Plugins, der das Feld auf die Seite gestellt hatte, wo ein Besucher es ausfüllen konnte.
• Eine Abweisung wegen Community-Reputation über einem Drittanbieter-Formular sprach vom Zurücksetzen des Passworts. Ein abgewiesenes Kontaktformular sagt es jetzt in eigenen Worten.
• Drei deutsche Strings auf der Seite „Schutz” zeigten nach einer Latin-1-Rundreise in 2.1.61 kaputte Umlaute; das i18n-Gate lehnt jetzt eine Übersetzungsdatei mit diesem Muster ab.
• Vier Admin-Oberflächen hielten ihre eigene Liste der Formular-Adapter und waren mit der Tabelle nicht mitgewachsen. Sie lesen jetzt die Tabelle, sodass ein neuer Adapter sofort im Hinweis zum gesperrten Zustand, im Readiness-Deep-Link und in der Dashboard-Aktion auftaucht.
• Ein geschütztes Formular hinzuzufügen ist ein Aufruf. Regel, Wortlaut, Log-Zeile und Zähler sitzen hinter einem einzigen Einstiegspunkt, und ein Test nennt die Datei, sobald eine neue Oberfläche anfängt, Bewertungen selbst zu lesen.

Was sich für eine verwaltete Flotte ändert

Zwei Schlüssel kamen zum Schema der Fernwartungs-Einstellungen hinzu, reportedip_hive_form_proof_wpforms und reportedip_hive_form_proof_forminator, beide ab Business über die Schnellstart-Empfehlung standardmäßig eingeschaltet; nichts wurde entfernt oder in seiner Art verändert. Ein Dashboard, das das Schema nicht neu geladen hat, funktioniert weiter. Das Zählerpaar für Kommentare wandert über Migration v18, sofern ein Betreiber es nicht selbst gesetzt hat, und der entfernte Filter reportedip_hive_form_proof_buckets betraf nur eine Website, die ihn eingehängt hatte.

2.1.66 folgt auf 2.1.62, das den Audit-Trail zu einem Protokoll darüber machte, wer was geändert hat, und auf 2.1.57, das jede Einstellung auf eine Schutz-Seite legte. Die Plugin-Dokumentation führt die aktuelle Funktionsliste je Tarif, die Sensoren und ihre Standardwerte, und der Leitfaden zum Formular-Honeypot erklärt die vier Bewertungen, die jetzt alle Oberflächen teilen.