CreaCaptcha

Plugin Name: CreaCaptcha
Plugin URI: https://github.com/creationell-dev/creationell-captcha
Description: Datenschutzfreundlicher Proof-of-Work-Captcha, Firewall, Rate-Limiter, Under-Attack-Modus, E-Mail-Obfuskation und Bild-Code-Challenge — vollständig selbst-gehostet ohne externe Dienste.
Version: 1.1.2
Author: creationell® – die Werbeagentur marketing@creationell.de
Author URI: https://www.creationell.de/
Contributors: creationell-dev, JPKCom
Tags: captcha, spam, anti-spam, anti-bot, proof of work
Requires at least: 6.9
Tested up to: 7.1
Requires PHP: 8.3
Stable tag: 1.1.2
License: GPL-2.0-or-later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain: creationell-captcha
Domain Path: /languages

Schützt WordPress-Formulare und ganze Sites mit einem selbst-gehosteten Proof-of-Work-Captcha, Firewall, Rate-Limiter, Under-Attack-Interstitial, E-Mail-Obfuskation und optionaler Bild-Code-Challenge — ohne externe Dienste.

Description

CreaCaptcha ist ein vollständig selbst-gehostetes Schutz-Plugin für WordPress. Es kombiniert einen Proof-of-Work-Captcha auf Basis der MIT-Bibliothek altcha-org/altcha mit einer Firewall, einem per-IP-Rate-Limiter, einem Under-Attack-Modus, E-Mail-Obfuskation und einer optionalen Bild-Code-Challenge. Es gibt keine externen API-Aufrufe, kein Lizenz-Gate, keine SaaS-Anbindung und keine Telemetrie — alle Funktionen laufen lokal in WordPress.

Das Plugin schützt die vier WordPress-Kernformulare (Kommentare, Login, Registrierung, Passwort-Reset) sowie automatisch alle Formulare gängiger Form-Plugins (Contact Form 7, Forminator, WPForms, WooCommerce mit Checkout / My-Account-Login / Registrierung / Lost-Password). Eigene oder fremde Formulare lassen sich über den Shortcode [creationell_captcha], das Template-Tag creationell_captcha_widget() oder den generischen Interceptor (Pfad-Schutz) absichern.

Key Features

• Proof-of-Work-Captcha — Server stellt eine Challenge aus, Browser löst sie mit PBKDF2/SHA-256 oder Argon2id; kein Klick-Puzzle, keine Bilderkennung, keine Tracking-Cookies
• Vollständig selbst-gehostet — Keine externen Dienste, kein API-Key, kein Lizenz-Server. Datenfluss bleibt zu 100 % auf dem WordPress-Host
• Schutz der WordPress-Kernformulare — Kommentare, Login, Registrierung und Passwort-Reset einzeln zuschaltbar
• Vier Form-Plugin-Integrationen — Contact Form 7, Forminator, WPForms, WooCommerce (Checkout + My-Account-Login + Registrierung + Lost-Password) mit Auto-Inject und Server-Verifikation
• Generischer Interceptor — Eigene Form-Pfade per URL-Muster (mit *-Wildcards und !-Ausschluss) schützen, fail-closed
• Action-Schutz — admin-post.php / admin-ajax.php-Aktionen über die action-Liste absichern, mit *-Wildcards und !-Ausschluss
• Inject-Pfade — Auf konfigurierten Pfaden wird die Sicherheitsabfrage automatisch in jedes </form> injiziert (idempotent — bereits geschützte Formulare werden übersprungen)
• Shortcode & Template-Tag — [creationell_captcha] oder creationell_captcha_widget() für freihändigen Einbau in beliebige Formulare; CF7-Form-Tag mit identischem Namen
• Bild-Code-Challenge — Optionale zweite Stufe nach PoW: serverseitig gerendertes PNG (PHP-GD, mitgelieferte DejaVu-TTF), 4–8-stelliger Code mit Anti-OCR-Verzerrung; Trigger wahlweise Immer, Under-Attack, Rate-Limit-Schwelle oder Watch-Liste (OR-verknüpft)
• Under-Attack-Modus — HTTP-503-Interstitial mit invisiblem PoW-Widget für anonyme Besucher; HMAC-signiertes Pass-Cookie für die konfigurierte Dauer
• Firewall — IP-Blocklist & -Allowlist (exakt + CIDR, v4 & v6), User-Agent-Blocklist (Wildcard), Proxy-Modus mit konfigurierbarem Forwarded-Header
• Vertrauenswürdige Proxies — Eigene IP-/CIDR-Liste, Cloudflare-IP-Auto-Refresh aus den offiziellen Listen, optionaler Trust von Private-Netzen; nur dann wird X-Forwarded-For ausgewertet
• Rate-Limit — Per-IP Fixed-Window-Counter mit drei Scopes (Core-Formulare / alle Formulare / global); konfigurierbarer Max-Wert, Fenster und Retry-After
• Drei Bypass-Mechaniken — IP-Allowlist (CIDR), User-Agent-Wildcard-Liste und Cookie-Bypass (name=wert); Treffer umgehen Firewall, Rate-Limit, Captcha und Under-Attack
• Analytics & Event-Log — Aggregierte Tages- und Stundenzähler je Ereignistyp (verified / failed / firewall / ratelimit / underattack / challenge); optional detaillierte Event-Tabelle mit IP, Pfad, Plugin, Aktion, Form-ID, Grund, User-Agent, Referrer, User-ID und Request-Body-Fingerprint
• DSGVO-konforme IP-Anonymisierung — Standard: IPv4 auf das letzte Oktett, IPv6 auf die letzten 80 Bit trunkiert
• Statistik-Dashboard — Drei Tabs (Übersicht / Verlauf / Ereignisse), vier Zeitfenster (24 h / 7 Tage / 30 Tage / 90 Tage), Filterleiste, seitenweises Blättern und CSV-Export
• E-Mail-Obfuskation — Verschleiert mailto:-Links und Klartextadressen per XOR-Hex; zwei Modi (Content-Filter oder Ganzseiten-Buffer für theme-hartkodierte Adressen)
• Widget-Customization — Anzeigemodus (Standard / schwebend / Overlay / Bar / Invisible), Interaktionstyp, Auto-Trigger, Theme, Branding-Toggle, Akzentfarbe, eigenes CSS und Strings-Override für alle Übersetzungstexte
• Backend-UI mit sechs Tabs — Captcha, Formulare, Firewall, Under-Attack, Analytics, E-Mail-Schutz — alles unter einem gemeinsamen „Änderungen speichern”
• Werkzeuge-Seite — Export / Import der Einstellungen als JSON, vollständiger Werksreset und ein gesonderter „Standardwerte laden”-Schritt (Listen bleiben erhalten)
• WP-CLI-Integration — Befehlsgruppe wp creacaptcha für Status, Diagnose, Modul-Aktivierung, Listen, Event-Log, Cloudflare-Refresh und Bypass-Tests
• Self-Hosted-Updater — Updates direkt aus GitHub-Releases mit SHA-256-Manifest-Verifikation (timing-safe hash_equals)
• Kein Lizenz-Gate — Alle Funktionen sind dauerhaft aktiv. GPL-2.0-or-later

Installation

1. Den Plugin-Ordner creationell-captcha nach /wp-content/plugins/ hochladen — entweder als ZIP über Plugins → Installieren → Plugin hochladen oder per FTP/SSH/wp plugin install.
2. Unter Plugins → Installierte Plugins das Plugin CreaCaptcha aktivieren.
3. Den neuen Menüpunkt CreaCaptcha im WordPress-Adminbereich öffnen.
4. Unter CreaCaptcha → Einstellungen im Tab Captcha den Master-Toggle prüfen (Standard: aktiv) und den Tab Formulare durchgehen, um WordPress-Kernformulare und Form-Plugins zu aktivieren.
5. Falls eigene Formular-Pfade abgesichert werden sollen: im Tab Captcha → Interceptor die Liste Geschützte Pfade pflegen.
6. Empfohlen: einmal CreaCaptcha → Statistik öffnen, damit der Event-Log aktiviert werden kann (optional — die Aggregat-Statistik läuft auch ohne).

Anforderungen

• WordPress 6.9 oder höher
• PHP 8.3 oder höher
• Für die Bild-Code-Challenge: PHP-Erweiterung GD
• Für den optionalen Argon2id-Algorithmus: PHP-Erweiterung Sodium

Das Plugin prüft die Mindestversionen beim Aktivieren und zeigt im Admin-Bereich eine deutliche Hinweisleiste, wenn die Umgebung zu alt ist.

Updates

Updates kommen direkt aus dem GitHub-Repo. Der eingebaute Self-Hosted-Updater (includes/class-plugin-updater.php) prüft regelmäßig das Manifest, vergleicht Versionen und installiert das offiziell signierte ZIP samt SHA-256-Checksum.

Dokumentation

Das Plugin aktualisiert sich über das Update-Manifest selbst — es ist kein Eintrag im WordPress.org-Plugin-Verzeichnis erforderlich.

Konfiguration

Sämtliche Einstellungen liegen unter CreaCaptcha → Einstellungen und sind in sechs Tabs gegliedert. Alle Tabs teilen ein gemeinsames „Änderungen speichern”.

Tab: Captcha

Steuert die Proof-of-Work-Engine, das Widget-Aussehen und die Bild-Code-Challenge.

Section „Engine”

Section „WordPress-Kernformulare”

Vier unabhängige Toggles für Kommentare, Login, Registrierung und Passwort-Reset.

Section „Widget-Erscheinungsbild”

Die Floating-Felder sind nur aktiv, wenn der Anzeigemodus auf schwebend steht — sonst werden sie ausgegraut.

Sprache: CreaCaptcha erkennt die Widget-Sprache automatisch aus der WordPress-Locale (get_locale()) und enqueued die passende von 20 vendorierten ALTCHA-Locale-Dateien (DE, EN, FR-FR/CA, ES-ES/419, IT, NL, PT-PT/BR, PL, CS, SK, DA, SV, FI, NB, HU, RO, EL). Eine nicht abgedeckte WP-Locale lässt das Widget auf seine eigene <html lang>/Browser-Sprach-Detection bzw. Englisch zurückfallen. Einzelne Begriffe lassen sich weiterhin über das Setting Übersetzungstexte überschreiben anpassen — Auto-Locale und Override greifen kombiniert, der Override gewinnt pro Schlüssel.

Section „Bild-Code-Challenge”

Mehrere Trigger sind OR-verknüpft. Wenn die Code-Challenge eingerichtet, aber GD nicht verfügbar ist, deaktiviert sich das Feature stillschweigend und zeigt eine Warn-Notice.

Section „Interceptor”

Der Interceptor läuft als früher Request-Guard auf init und arbeitet fail-closed: Fehlt eine Verifikation, wird die Anfrage abgelehnt (HTTP 403, AJAX-Requests bekommen JSON-403).

Tab: Formulare

Vier Toggles für die WordPress-Kernformulare (siehe Captcha-Tab — werden hier als Komfort-Kopie gespiegelt) sowie sechs Toggles für die Form-Plugin-Integrationen.

CF7 bietet zusätzlich einen Form-Tag [creationell_captcha], mit dem die Position der Sicherheitsabfrage frei wählbar ist. Forminator/WPForms nutzen Auto-Inject standardmäßig vor dem Submit-Button — der Filter creationell_captcha_forminator_autoinject (bzw. creationell_captcha_wpforms_autoinject) erlaubt das Deaktivieren je Formular.

Hinweis: WooCommerce-Produktbewertungen sind WordPress-Kommentare und werden bereits durch WordPress-Kommentare schützen abgedeckt. Es gibt absichtlich keinen separaten Sub-Toggle.

Tab: Firewall

Vier Sections in dieser Reihenfolge: Proxy → Firewall → Bypass → Rate-Limit.

Section „Proxy & IP-Ermittlung”

Zusätzlich kann die wp-config-Konstante CREATIONELL_CAPTCHA_TRUSTED_PROXIES (Array von CIDRs) die Trust-Liste ergänzen.

Section „Firewall”

Section „Bypass”

Drei Eintragsarten, die jeweils Firewall, Rate-Limit, Captcha und Under-Attack-Modus umgehen.

Treffer auf Formular-Ebene erscheinen im Event-Log als verified-Eintrag mit passendem Grund (IP-Allowlist / UA-Bypass / Cookie-Bypass).

Section „Rate-Limit”

Bei Überschreitung sendet der Plugin-Stack HTTP 429 mit Retry-After-Header.

Tab: Under-Attack

wp-admin, REST-API und Cron sind automatisch ausgenommen. Der Kill-Switch CREATIONELL_CAPTCHA_DISABLE (wp-config-Konstante) hebt den Modus global auf.

Section „Erscheinungsbild”

Optional — leere Felder verwenden die Standardwerte. Sichtbar, sobald der Under-Attack-Modus aktiv ist (sonst ausgegraut).

Tab: Analytics

Tab: E-Mail-Schutz

Im Buffer-Modus werden auch theme-hartkodierte mailto:-Links und Klartextadressen im Footer/Header erfasst. <head>, <script> und <style> bleiben unberührt. Feed-Requests und der Admin-Bereich umgehen die Obfuskation immer.

Shortcode & Template-Tag

[creationell_captcha]

Bettet das ALTCHA-Widget an beliebiger Stelle ein.

Bei aktiviertem CF7-Plugin ist [creationell_captcha] zusätzlich als CF7-Form-Tag verfügbar und kann direkt im CF7-Form-Editor platziert werden.

creationell_captcha_widget()

Template-Tag mit identischer Wirkung. Nützlich, wenn ein Shortcode nicht in Frage kommt (z. B. in Theme-PHP-Templates):

<form method="post">
    <!-- … Felder … -->
    <?php creationell_captcha_widget(); ?>
    <button type="submit">Senden</button>
</form>

Bei serverseitiger Verifikation immer auch den Pfad in Geschützte Pfade eintragen (siehe nächster Abschnitt) — sonst läuft eine manipulierte Submission ungeprüft durch.

Geschützte Pfade & Interceptor

Der Interceptor läuft auf init und ist die generische Schutzschicht für eigene Formulare. Konfiguriert wird er im Captcha-Tab.

Pfad-Muster

[creationell_captcha]-Shortcode und Template-Tag rendern nur das Widget. Die Server-Verifikation übernimmt der Interceptor anhand der Pfad-Liste.

/kontakt              ← exakt
/forms/*              ← Wildcard
!/forms/whitelisted   ← Ausschluss (mit ! kombinierbar)

!-Muster greifen vor positiven Mustern. So lässt sich /forms/* schützen, ein einzelner Sub-Pfad aber gezielt freistellen.

Action-Schutz

Für AJAX-/Admin-Post-Endpoints reicht die Pfad-Liste nicht — Requests gehen alle an admin-ajax.php oder admin-post.php. Die Liste Geschützte Aktionen wertet stattdessen das action-Feld (POST oder GET) aus:

my-custom-action
form/*
!form/internal

Action-Treffer überschreiben den is_admin()-Bypass — die Verifikation läuft auch dann, wenn der Aufruf aus dem Admin-Backend käme.

Auto-Inject auf Pfaden

Die Inject-Pfade-Liste fügt die Sicherheitsabfrage automatisch vor jedem </form> der passenden Seite ein, ohne dass das Theme oder ein Plugin angepasst werden muss. Idempotent: Formulare mit bereits eingebautem Widget bleiben unangetastet.

Bypass-Kette

Vor jeder Verifikation läuft die Bypass-Kette in dieser Reihenfolge:

1. Kill-Switch CREATIONELL_CAPTCHA_DISABLE (wp-config-Konstante)
2. Master-Toggle aus
3. Request-Methode GET (Renderpfad — Verify nur auf POST/PUT/DELETE/PATCH)
4. CLI / Cron / XML-RPC (nicht-Browser-Kontexte)
5. is_admin() — wird durch Action-Schutz überschrieben, sobald die action auf einer geschützten Liste steht
6. REST-API-Eigen-Endpoints (Challenge-/Code-Routes)
7. WordPress-Kernformulare (siehe Tab Formulare)
8. edit_posts-Capability (eingeloggte User)
9. Bei aktiviertem Toggle: alle eingeloggten User
10. Globale Bypass-Quellen: IP-Allowlist, UA-Allowlist, Cookie-Bypass

Greift einer der Schritte, wird die Anfrage durchgelassen. Auf Formular-Ebene wird der erfolgreiche Bypass als verified-Event mit Grund-Annotation geloggt.

Entwickler-Filter

// Pfad/Action-Listen runtime ergänzen
add_filter( 'creationell_captcha_interceptor_paths', function ( array $paths ): array {
    $paths[] = '/api/mein-form/*';
    return $paths;
} );

add_filter( 'creationell_captcha_interceptor_actions', function ( array $actions ): array {
    $actions[] = 'mein_plugin_form';
    return $actions;
} );

// Eigenen Bypass anhängen (true = durchlassen)
add_filter( 'creationell_captcha_interceptor_bypass', function ( bool $bypass ): bool {
    return $bypass || ( defined( 'MY_DEV_BYPASS' ) && MY_DEV_BYPASS );
} );

// Custom geschützten Pfad zur Laufzeit registrieren
creationell_captcha_protect_path( '/checkout/step2' );

Bild-Code-Challenge

Die Bild-Code-Challenge ist eine zweite Stufe nach der PoW-Verifikation — kein Ersatz. Der Browser löst zuerst die PoW, der Server schickt dann optional ein PNG mit einem 4–8-stelligen Code, den der Nutzer abtippt.

Trigger-Bedingungen

Mehrere Trigger sind OR-verknüpft.

REST-Endpoints

Tokens sind opake 32-Hex-Server-Identifier; der erwartete Code lebt nur in einem WP-Transient und verlässt den Server nie. Die zurückgegebene Payload geht durch den bestehenden Verify-Pfad.

Rendering

PHP-GD mit vendorierter DejaVuSans-Bold-TTF (assets/fonts/captcha.ttf) und naiver Anti-OCR-Verzerrung (rotierte Zeichen, Querlinien, Rauschen). Fehlt die TTF, fällt der Renderer auf den GD-Bitmap-Font 5 zurück.

Fehlt GD selbst, deaktiviert sich das Feature stillschweigend und der Section-Renderer zeigt eine Warn-Notice.

Bypass-Schutz

Engine::verify() lehnt jeden Payload ab, in dem parameters.data.ccode clientseitig gesetzt ist — ein Angreifer kann den originalen Payload nicht recyclen, um die Code-Stufe zu überspringen.

Under-Attack-Modus

Der Under-Attack-Modus ist ein Notfall-Schalter für aktive Bot-Wellen. Bei aktivem Modus liefert WordPress für jeden anonymen Besucher ein HTTP-503-Interstitial mit einem invisiblen ALTCHA-Widget aus. Erst nach bestandener PoW-Sicherheitsabfrage setzt der Server ein HMAC-signiertes Pass-Cookie und lässt den Browser auf die eigentliche Seite.

Ablauf

1. Anonymer Besucher öffnet beliebige Seite
2. template_redirect fängt den Request ab, zeigt das Interstitial
3. Browser löst die PoW-Sicherheitsabfrage im Hintergrund
4. Server prüft, signiert das Pass-Cookie creationell_captcha_ua_pass (HMAC, gültig für die konfigurierte Pass-Dauer)
5. Browser wird mit Location-Header auf die ursprüngliche URL umgeleitet
6. Folgende Requests passieren den Modus, bis das Cookie abläuft

wp-admin, REST-API und Cron sind automatisch ausgenommen — die Site bleibt von innen administrierbar. Eingeloggte User sind per Default ebenfalls ausgenommen.

Kill-Switch

Definiert man define( 'CREATIONELL_CAPTCHA_DISABLE', true ); in wp-config.php, sind alle CreaCaptcha-Funktionen — inklusive Under-Attack — global deaktiviert. Praktisch für den Fall, dass die Site sich selbst aussperrt.

Statistik & Event-Log

Aggregat-Statistiken

Immer aktiv, datenschutzfreundlich, keine personenbezogenen Daten. Zwei Counter-Tabellen in wp_options:

• creationell_captcha_analytics — Tageszähler je Ereignistyp
• creationell_captcha_analytics_hourly — Stundenzähler je Ereignistyp (für die 24-h-Sicht)

Detail-Event-Log

Optional, schaltbar im Analytics-Tab. Schreibt in die eigene Tabelle <prefix>creationell_captcha_events mit 15 Spalten:

Statistik-Dashboard

CreaCaptcha → Statistik liefert drei Tabs:

Die Filter-Leiste im Ereignisse-Tab kombiniert Freitextsuche (IP + Pfad), Ereignistyp-Filter und Von/Bis-Datumsbereich.

Performance

Seit v0.26.0:

• Analytics::record() sammelt Counter-Deltas in Class-Statics und flusht sie auf shutdown in einem einzigen get_option/update_option-Paar je Counter-Tabelle — statt zwei Roundtrips pro Event
• Composite-Index event_type_created (event_type, created_at) auf der Events-Tabelle: typgefilterte Range-Queries laufen als reiner Index-Range-Scan ohne Filesort
• creationell_captcha_get_settings() cacht das Default-Merge-Ergebnis pro Request

E-Mail-Schutz (Obfuskation)

Zwei Modi

Verschleierung

mailto:-Hrefs werden zu href="#" data-cce="<hex>", Klartext-Adressen zu <span data-cce="<hex>">[E-Mail-Adresse — bitte JavaScript aktivieren]</span>. Der Hex-String ist eine XOR-Verschlüsselung der Adresse mit einem einmaligen Per-Page-Key.

Decoder

assets/js/email-obfuscation.js läuft auf DOMContentLoaded, bindet sich auf alle [data-cce]-Elemente und stellt die Original-Adresse im Browser wieder her.

Ausnahmen

<head>, <script>, <style> werden im Buffer-Modus übersprungen. Feed-Requests, wp-admin und der Kill-Switch umgehen die Obfuskation immer.

WP-CLI

Alle Plugin-Funktionen sind per wp creacaptcha automatisierbar. Eine Übersicht aller Befehle:

wp help creacaptcha

Betriebsbefehle

Die <feature>-Schlüssel für enable/disable: captcha, comments, login, registration, password-reset, cf7, forminator, wpforms, woocommerce, wc-checkout, wc-login, wc-registration, wc-lost-password, firewall, ratelimit, under-attack, analytics, event-log, email-obfuscation, code-challenge.

Einstellungen

Listen-Pflege

Jede Liste hat denselben Subcommand-Baukasten: add <eintrag>, remove <eintrag>, list, clear.

Cloudflare-Cache

Der frühere Alias wp creacaptcha refresh-cloudflare-ips wurde mit v1.0.1 entfernt — bitte wp creacaptcha cloudflare refresh verwenden.

Event-Log

Die Werkzeuge-Seite im Backend (siehe nächster Abschnitt) bietet dieselben Export-/Import-/Reset-/Load-Defaults-Aktionen.

Werkzeuge

CreaCaptcha → Werkzeuge ist die Backend-Entsprechung der wichtigsten CLI-Aktionen. Fünf Karten:

Developer Reference

Die wichtigsten Konstanten, Hooks und Filter im Überblick:

Konstanten (wp-config.php überschreibbar)

Hooks (Actions)

Hooks (Filter)

REST-Endpoints

Alle Routes unter dem Namespace creationell-captcha/v1:

Wichtige PHP-Helper

// Schutz für eigene Pfade registrieren
creationell_captcha_protect_path( '/checkout/step2' );

// Widget rendern (Template-Tag-Variante)
creationell_captcha_widget();

// Settings memoiziert laden
$settings = creationell_captcha_get_settings();

// Bypass-Auswertung manuell aufrufen
$bypass_active = creationell_captcha_request_bypassed();

Architektur

Das Plugin folgt einer require-basierten Classic-WordPress-Architektur. Die Klassen liegen unter Creationell\Captcha\… in includes/class-*.php; prozedurale Bootstrap-Helper in includes/<modul>.php. Die geprefixte ALTCHA-Library landet via Strauss in lib/Creationell\Captcha\Vendor\…. Es gibt keinen Composer-Autoloader im Release-ZIP — alle Requires sind explizit.

FAQ

Sendet CreaCaptcha Daten an externe Dienste?

Nein. Das Plugin arbeitet vollständig selbst-gehostet — es gibt keine API-Aufrufe, kein Telemetrie-Backend, keinen Lizenz-Check und keine SaaS-Anbindung. Die einzige optionale externe Anfrage ist der Cloudflare-IP-Refresh aus den offiziellen Cloudflare-Listen, der ausschließlich auf expliziten Toggle läuft.

Welcher Captcha-Algorithmus läuft im Hintergrund?

CreaCaptcha nutzt die offizielle MIT-Bibliothek altcha-org/altcha. Standardmäßig kommt PBKDF2/SHA-256 zum Einsatz (kein PHP-Extension-Bedarf). Optional lässt sich auf Argon2id umschalten, dafür wird ext-sodium benötigt.

Funktioniert das Plugin ohne JavaScript?

Nein — die Proof-of-Work-Sicherheitsabfrage muss vom Browser gelöst werden. Ohne JavaScript erscheint das Widget als Hinweistext, und die Server-Verifikation wird die Submission abweisen. Für ein vollständig JS-loses Schutz-Setup ist die Firewall+Rate-Limit-Schicht der richtige Ansatz.

Welche Form-Plugins werden unterstützt?

Mit dedizierten Integrationen: Contact Form 7, Forminator, WPForms (Lite und Pro), WooCommerce (Checkout, My-Account-Login, Registrierung, Lost-Password). Beliebige andere Formulare lassen sich über [creationell_captcha] und die Geschützte-Pfade-Liste absichern. Für AJAX-/Admin-Post-Endpoints gibt es zusätzlich die Geschützte-Aktionen-Liste.

Wie schütze ich ein eigenes Formular auf einer beliebigen Seite?

Drei Schritte: (1) Den Shortcode [creationell_captcha] oder das Template-Tag creationell_captcha_widget() ins Formular einbauen. (2) Den Pfad der Seite oder den Submit-Pfad in Captcha → Interceptor → Geschützte Pfade eintragen. (3) Bei AJAX-/Admin-Post-Submissions zusätzlich den action-Namen in Geschützte Aktionen. Der Interceptor verifiziert dann automatisch jede Submission.

Was passiert mit ungelösten Bot-Submissions?

Der Server lehnt die Submission ab. Bei klassischen Formularen erhält der Browser die normale Validierungs-Fehlermeldung des jeweiligen Plugins. Bei AJAX wird 403 Forbidden mit JSON-Body geliefert. Der Bot bekommt keine Hilfe in Form von Hinweisen, woran das Captcha gescheitert ist — der reason landet nur im Event-Log.

Wie kann ich mich selbst aussperren — und wie komme ich wieder rein?

Wer durch eigene Firewall-Regeln, Rate-Limit oder einen kaputten Under-Attack-Modus ausgesperrt wird, kann zu jeder Zeit per wp-config.php den Kill-Switch setzen:

define( 'CREATIONELL_CAPTCHA_DISABLE', true );

Sofort sind alle Module aus — Firewall, Rate-Limit, Captcha, Under-Attack, Interceptor. Anschließend lassen sich die problematischen Einstellungen im Backend korrigieren. Ohne SSH/FTP-Zugriff bleibt der direkte Datenbank-Eingriff: wp option update creationell_captcha_settings … oder per wp creacaptcha settings load-defaults.

Funktioniert das Plugin hinter Cloudflare oder einem Reverse-Proxy?

Ja. Im Tab Firewall unter „Proxy & IP-Ermittlung” den Proxy-Modus aktivieren und den passenden Forwarded-Header wählen. Für Cloudflare zusätzlich „Cloudflare-IPs vertrauen” und optional den Auto-Refresh einschalten — die offiziellen Cloudflare-v4/v6-Ranges werden dann täglich neu geladen. Ohne Trust-Konfiguration wird der Header ignoriert, damit Angreifer nicht beliebige IPs spoofen können.

Wie viel Performance kostet das Plugin?

Sehr wenig. Die Captcha-Berechnung läuft im Browser, nicht auf dem Server. Die Firewall-Auswertung ist eine reine IP-/Pattern-Prüfung (keine externen Lookups). Analytics-Counter werden seit v0.26.0 pro Request gesammelt und in einem einzigen DB-Roundtrip auf shutdown geschrieben. Das Event-Log nutzt seit derselben Version einen Composite-Index, der typgefilterte Dashboard-Queries ohne Filesort beantwortet.

Wie DSGVO-konform ist das Plugin?

Out-of-the-box ist die IP-Anonymisierung im Event-Log aktiv (IPv4 auf letztes Oktett, IPv6 auf letzte 80 Bit trunkiert). Aggregat-Zähler enthalten keinerlei personenbezogene Daten. Im Event-Log werden keine Query-String-Werte (GET-Token, Magic-Links, API-Keys) gespeichert — der Pfad wird vor dem Schreiben auf den reinen Pfadanteil reduziert. Request-Body-Fingerprints enthalten nur Feldnamen und Wertlängen; sensitive Feldnamen werden zusätzlich gehasht.

Wie deaktiviere ich das Plugin sauber?

Über Plugins → Installierte Plugins deaktivieren reicht für den Betrieb. Wer auch die Daten loswerden will, kann das Plugin anschließend löschen — der uninstall.php-Cleanup entfernt alle Options, Transients (inklusive _cc_*-Caches und _git_update_*-Locks) sowie die Event-Tabelle.

Funktioniert das Plugin mit Multisite?

Ja, allerdings pro Site einzeln aktivierbar. Es gibt aktuell keine Network-Activate-Logik mit zentralen Settings — jede Site hat ihre eigene Konfiguration. Network-weite Aktivierung ist möglich, hat aber denselben Effekt wie eine Aktivierung pro Site.

Kann ich CreaCaptcha parallel zu einem anderen Captcha-Plugin betreiben?

Technisch ja — die Code-Pfade kollidieren nicht. wp creacaptcha doctor prüft auf bekannte Captcha-Plugins (reCAPTCHA, hCaptcha, Turnstile, ALTCHA-WordPress) und warnt, weil zwei Captcha-Layer auf demselben Formular für den Nutzer unzumutbar werden. Empfehlung: nur eines aktiv lassen.

Wo finde ich Logs, wenn etwas nicht funktioniert?

Mit define( 'CREATIONELL_CAPTCHA_DEBUG', true ); (oder global WP_DEBUG) schreibt das Plugin Debug-Hinweise nach wp-content/debug.log. Zusätzlich liefert wp creacaptcha doctor einen kompletten Diagnose-Lauf, und das Event-Log zeigt alle abgewiesenen Requests samt Grund.

Wie aktualisiere ich auf eine neue Version?

Drei Wege: (1) Der eingebaute Self-Hosted-Updater zeigt neue Versionen automatisch im Plugins-Bildschirm — wie ein normales wp.org-Update. (2) ZIP von der GitHub-Release-Seite herunterladen und manuell über Plugins → Installieren → Plugin hochladen einspielen. (3) Per WP-CLI: wp plugin install --activate <release-url> mit der URL aus den GitHub-Releases.

Changelog

1.1.2

Fehlerbehebung: Der Passwort-Reset, den eine Administratorin oder ein Administrator im Backend für ein Benutzerkonto auslöst, funktioniert wieder.

• Der Knopf „Link zum Zurücksetzen senden” im Benutzerprofil und die Massenaktion „Passwort zurücksetzen senden” in der Benutzerliste brachen bei eingeschaltetem Passwort-Reset-Schutz mit der Meldung „Die Sicherheitsabfrage wurde nicht bestanden” ab, und es wurde keine E-Mail versendet. Ursache: Die Prüfung hing an einer WordPress-Schnittstelle, die nicht nur das öffentliche „Passwort vergessen”-Formular auslöst, sondern auch jeden administrativen und programmatischen Reset — dort ist aber nie eine Sicherheitsabfrage angezeigt worden, die man hätte lösen können.
• Ausgenommen sind ab jetzt genau die Aufrufe, die nachweislich nicht aus dem öffentlichen Formular stammen: administrative Resets im Backend durch Konten mit dem Recht zur Benutzerverwaltung sowie Aufrufe über die Kommandozeile, über Cron, über XML-RPC und über die REST-Schnittstelle. Die Ausnahme hängt am tatsächlichen Recht, nicht bloß am Backend-Kontext — ein unangemeldeter Aufruf kann sie deshalb nicht für sich beanspruchen.
• Am öffentlichen Formular ändert sich nichts: Es verlangt die Sicherheitsabfrage weiterhin, ebenso die WooCommerce-Seite „Passwort vergessen”. Auch für angemeldete Administratoren, die das öffentliche Formular benutzen, bleibt die Abfrage bestehen.

Das Update braucht keine Datenbank-Migration, es gibt keine neuen Einstellungen, und an gespeicherten Konfigurationen ändert sich nichts.

1.1.1

Wartungs-Release: Die mitgelieferten Fremdbestandteile stehen wieder auf dem aktuellen Stand. Für eine laufende Installation ändert sich nichts an der Konfiguration, es gibt keine neuen Einstellungen und keine Datenbank-Migration.

• Das mitgelieferte Captcha-Widget wurde von 3.0.9 auf 3.2.1 gehoben. Die Änderungen betreffen die Erkennung von Content-Security-Policy-Nonces, ein doppeltes Registrieren des Elements auf Seiten mit mehreren Formularen, die Ladereihenfolge der Sprachdateien und den Fokusrahmen in Safari. Der Umfang der mitgelieferten Sprachen ist unverändert.
• Die zugrundeliegende Proof-of-Work-Bibliothek wurde von 2.0.2 auf 2.1.0 gehoben. Sie weist eine Anfrage ohne Challenge-Signatur seit 2.0.3 selbst ab. Das Plugin tut das ohnehin schon länger selbst, und zwar früher in der Verarbeitung — die Prüfung liegt damit jetzt doppelt vor, statt nur einmal.
• Es lag zu keinem Zeitpunkt eine bekannte Schwachstelle vor: Für keinen der mitgelieferten Bestandteile war die ausgelieferte Version von einer veröffentlichten Sicherheitsmeldung betroffen — weder in 1.1.0 noch davor.

1.1.0

Sicherheits- und Härtungsrelease. Ein mehrtägiges, angriffsorientiertes Audit über die gesamte Codebasis und ein anschließendes Schluss-Review haben rund 90 Befunde ergeben; alle sind in dieser Version behoben. Der Schwerpunkt liegt auf den Stellen, an denen eine Anfrage identifiziert wird — Pfad, IP-Adresse, Anfragekontext —, auf der Captcha-Engine, dem Under-Attack-Modus, der Update-Kette und den Verwaltungswerkzeugen.

Das Update braucht keine Datenbank-Migration. Gespeicherte Einstellungen, Listen und Statistiken bleiben unverändert erhalten, und kein Wert wird automatisch umgeschrieben. Trotzdem wirken sich mehrere Änderungen auf eine laufende Installation aus — bitte zuerst den folgenden Abschnitt lesen.

Was sich für eine laufende Installation ändert:

• Alle bestehenden Zugangs-Cookies des Under-Attack-Modus werden einmalig ungültig. Wer beim Update gerade einen gültigen Zugang hat, sieht die Zwischenseite genau einmal erneut. Das Cookie ist ab dieser Version an Netzbereich und Browserkennung des Besuchers gebunden statt frei übertragbar; wechselt ein Besucher während der Zugangsdauer das Netz (Mobilfunk-Handover, WLAN/LTE, Dual-Stack), löst er einmal neu. Wer das nicht möchte, schaltet die Bindung über den neuen Filter creationell_captcha_underattack_pass_binding ab.
• IP-Adressen werden vor jedem Listenvergleich auf eine einheitliche Schreibweise gebracht. Auf Servern, die IPv4-Adressen in der IPv6-Mischschreibweise melden (z. B. nginx mit ipv6only=off), fangen Blockliste, Erlaubnisliste, vertrauenswürdige Proxies und der Proxy-Modus damit überhaupt erst an zu wirken. Bitte Block- und Erlaubnisliste nach dem Update einmal ansehen — eine Regel, die dort bisher wirkungslos war, greift jetzt.
• Ein CIDR-Bereich, der in der IPv4-Mischschreibweise notiert ist (::ffff:203.0.113.0/120), trifft keine Adresse mehr; einzelne Adressen in dieser Schreibweise wirken weiterhin. Bereiche bitte gewöhnlich schreiben (203.0.113.0/24). Bestehende Einträge dieser Art werden im Backend als Hinweis gemeldet.
• Auf Installationen, deren Rate-Limiter oder Under-Attack-Modus von den beiden vorstehenden Punkten betroffen ist, werden laufende Rate-Limit-Fenster einmalig zurückgesetzt: nach dem Update startet jeder betroffene Client mit einem leeren Zähler.
• Eine Freigabe für alle Adressen (0.0.0.0/0, ::/0) lässt sich in der IP-Erlaubnisliste, in der Liste vertrauenswürdiger Proxies und in der Watchliste nicht mehr neu speichern — im Backend wie über WP-CLI. Bereits gespeicherte Einträge bleiben unangetastet und wirksam, werden aber gemeldet. Die IP-Blockliste ist davon nicht betroffen: „alles sperren, Ausnahmen erlauben” bleibt möglich.
• Ein * in der User-Agent-Erlaubnisliste wirkt nicht mehr, ebenso wenig ein Bypass-Cookie-Eintrag ohne Wert. Wer damit bisher (versehentlich) alles durchgewunken hat, bekommt wieder den vollen Schutz.
• Der Proxy-Header für die Client-IP wird strikt als eine der vier angebotenen Auswahlmöglichkeiten behandelt. Ein davon abweichender Wert, der direkt in die Datenbank geschrieben wurde, fällt jetzt sauber auf X-Forwarded-For zurück, statt den Proxy-Modus still unwirksam zu machen. Auf einer solchen Installation liefert die Erkennung ab jetzt die echte Client-Adresse statt der Proxy-Adresse — wer Block- oder Erlaubnisliste auf die Proxy-Adresse eingestellt hatte, sollte diese Listen prüfen.
• Neu ist ein ausblendbarer Hinweis im Backend, der gespeicherte Konfigurationen meldet, die den Schutz ganz oder teilweise aufheben (Totalfreigaben, wirkungslos gewordene Bereichsschreibweisen, Muster, die auf jede Browserkennung passen). Der Hinweis meldet nur, er ändert nichts. Kommt später eine weitere Fundklasse dazu, erscheint ein zuvor weggeklickter Hinweis erneut. Ohne solche Altlasten sieht eine Installation nichts davon.
• Statistik und Ereignis-Log zeigen Einträge anders an: Der Pfad wird jetzt so protokolliert, wie WordPress die Anfrage tatsächlich geroutet hat, die IP-Darstellung wechselt auf den betroffenen Servern (siehe oben) am Update-Datum die Schreibweise, und die Spalte „Verifizierungsdaten” bleibt bei Firewall-, Rate-Limit-, Under-Attack- und Challenge-Ereignissen künftig leer. Bestandszeilen bleiben unverändert; Auswertungen, die nach IP gruppieren, zeigen am Update-Datum einen Bruch.
• Der CSV-Export prüft jetzt vor dem ersten Byte, ob er liefern kann, und lehnt sonst mit einem Hinweis ab: fehlende Tabelle, leere Treffermenge oder mehr als 50.000 Zeilen. Der letzte Fall ist der einzige, der einen bisher funktionierenden Ablauf blockiert — Abhilfe: Zeitraum eingrenzen oder den neuen Filter creationell_captcha_export_max_rows hochsetzen. Außerdem liefert der Export jetzt genau den Bestand, der beim Klick vorlag, und bei parallelem Schreibbetrieb keine doppelten Zeilen mehr.
• Die Aufbewahrungsfrist des Ereignis-Logs wird jetzt von einem eigenen täglichen Cron-Termin durchgesetzt (creationell_captcha_prune_events) — auch dann, wenn das Ereignis-Log abgeschaltet ist. Wer den Log abgeschaltet hat und die alten Zeilen als Archiv behalten wollte, sichert sie vor dem Update. Umgekehrt läuft die Aufbewahrungsfrist bei gesetztem CREATIONELL_CAPTCHA_DISABLE gar nicht mehr; wer den Schalter dauerhaft gesetzt hat und sich auf das automatische Aufräumen verlassen hat, muss das jetzt selbst erledigen.
• Die Ereignis-Tabelle wird an einer anderen Stelle angelegt als bisher, nämlich beim Schreiben der Einstellungs-Option statt in deren Prüfung. Neu abgedeckt sind damit WP-CLI und wp option update. Nicht mehr abgedeckt ist ein Speichern, das keinen Wert ändert — dafür ist wp creacaptcha repair der benannte Weg.
• Nach einem Plugin-Update über WP-CLI läuft die Schema-Prüfung nicht mehr beim nächsten beliebigen Seitenaufruf, sondern erst beim nächsten Besuch im Backend durch einen Benutzer mit der Berechtigung manage_options. Für das Update über das Backend ändert sich nichts.
• Der eingebaute Updater bricht ab, statt ungeprüft zu installieren: ohne gültige Prüfsumme, bei einer Paket-URL ohne HTTPS, bei einem unbrauchbaren oder gerade nicht erreichbaren Update-Manifest. Ist die Manifest-Quelle nicht erreichbar, lässt sich das Plugin so lange nicht per Ein-Klick-Update aktualisieren; der manuelle ZIP-Upload über „Plugin hochladen” bleibt jederzeit möglich.
• Einstellungs-Import, Werksreset und Schreibvorgänge über WP-CLI setzen jetzt durch, was sie angeben. Bisher wurden Werte für gerade ausgeschaltete Funktionsbereiche still auf den Altzustand zurückgedreht, und der Werksreset ließ die betroffenen Listen stehen. Ungültige Listeneinträge, die an den regulären Schreibwegen vorbei in die Datenbank gelangt sind, überleben „Standardwerte laden” nicht mehr.
• WP-CLI meldet Fehler jetzt auch als Fehler. Aufrufe, die bisher einen abgelehnten Wert mit Erfolg quittierten, enden mit Exit-Code 1; leere JSON-Ausgaben liefern [] statt Klartext; Steuerzeichen in Log-Ausgaben werden maskiert; settings export --file= schreibt die Datei mit den Rechten 0600. Kein bisher korrekter Aufruf wird dadurch zum Fehler — aber eigene Skripte, die auf Exit-Codes oder auf die bisherige Textausgabe aufsetzen, sollten einmal geprüft werden.
• wp creacaptcha doctor hat zwölf zusätzliche Prüfzeilen bekommen und meldet in mehreren bestehenden Prüfungen jetzt das, was sie tatsächlich prüfen. Dadurch kann sich der Exit-Code in beide Richtungen ändern: ein bisheriger Dauer-Alarm kann enden, und an anderer Stelle kann erstmals eine Warnung oder ein Fehler erscheinen. Monitoring, das den Exit-Code auswertet, bitte einmal nachziehen.
• An der WordPress-Anmeldung wird die Sicherheitsabfrage jetzt bei jedem interaktiven Anmeldeversuch verlangt, auch bei einem fehlgeschlagenen. Anmeldeformulare, die ein Theme oder Plugin über wp_login_form() erzeugt, bekommen jetzt selbst ein Widget eingesetzt und scheitern nicht mehr an der Prüfung. Die Anmeldung über das WooCommerce-Kundenkonto läuft unverändert über den eigenen Schalter dafür.
• Beim Pfad- und Action-Schutz greifen Pfadmuster jetzt auf dem URL-dekodierten Pfad, ein Action-Name wird in POST- und GET-Daten gleichermaßen erkannt, und ein ausschließlich per Filter ergänztes Action-Muster wirkt jetzt auch im Backend-Kontext. Wer diesen Filter benutzt, bekommt dort erstmals den Schutz, den er erwartet hat — dort können also Abweisungen auftreten, wo bisher stillschweigend nichts geprüft wurde.
• Bei aktivierter E-Mail-Obfuskation werden Adressen innerhalb von <textarea> und <template> nicht mehr verschleiert: Der Inhalt dieser Elemente ist Eingabe- bzw. Vorlagentext, und die Verschleierung hat ihn verfälscht. Umgekehrt verarbeitet die Obfuskation jetzt wieder Seiten, bei denen sie an einem ungewöhnlich notierten Attribut abgebrochen ist — auf solchen Seiten werden ab jetzt auch die Adressen hinter dieser Stelle verschleiert.
• Im Ganzseiten-Puffer-Modus der E-Mail-Obfuskation werden Antworten, die kein HTML sind, und Antworten über 2 MiB unverändert durchgereicht. Die Größengrenze lässt sich über den neuen Filter creationell_captcha_email_buffer_max_bytes anheben oder aufheben.
• Bei aktiver Bild-Code-Challenge gibt die Prüfroute den eingereichten Nachweis unverändert zurück, statt einen neuen auszustellen; Fehlversuche auf denselben Bildcode sind auf fünf begrenzt (Filter creationell_captcha_code_max_attempts), danach ist der Code verbraucht. Ist die Bild-Code-Challenge ausgeschaltet, sind ihre beiden REST-Endpunkte gar nicht mehr registriert.
• Im Under-Attack-Modus landet ein Besucher nach bestandener Prüfung wieder auf der Seite, die er angefordert hat, statt im Backend. Schlägt die Ausstellung des Zugangs fehl, rechnet der Besucher nicht mehr umsonst.
• Deaktivieren und Deinstallieren räumen mehr auf als bisher: zusätzliche Cron-Termine, abgelaufene Einmal-Verbrauchsmarken und — bei netzwerkweiter Aktivierung — die Daten jeder Site des Netzwerks statt nur der gerade aktuellen. Auf sehr großen Netzwerken dauern beide Vorgänge entsprechend länger. Die Deinstallation entfernt zusätzlich eine Benutzer-Einstellung je Administrator, der den Härtungshinweis weggeklickt hatte.
• Eigenes Custom-CSS wird an der Ausgabestelle zusätzlich gehärtet (tag-eröffnende Zeichen werden entfernt), und die Längenbegrenzung von Text- und Textblockfeldern zählt jetzt Zeichen statt Bytes — Umlaute und Emoji werden dadurch nicht mehr mitten im Zeichen abgeschnitten.

Sicherheit und Härtung:

• Die Erkennung des angefragten Pfads wurde auf eine gemeinsame Wurzel umgestellt. Pfad-Schutz, Widget-Injektion, Rate-Limiter, REST-Erkennung, Firewall-Kontext und Ereignis-Log beantworten die Frage „welchen Pfad hat diese Anfrage” jetzt identisch; zuvor konnten sie sich unterscheiden, und der Pfad-Schutz ließ sich dadurch umgehen.
• Ebenso vereinheitlicht ist die Erkennung von REST-Anfragen: Eine Anfrage gilt nur noch dann als REST-Anfrage, wenn WordPress sie tatsächlich an die REST-API übergibt. Die Ausnahmen, die für echte REST-Anfragen gelten, greifen damit nicht mehr für Anfragen, die nur so aussehen.
• Die Sicherheitsabfrage an der WordPress-Anmeldung konnte unter bestimmten Umständen umgangen werden. Die Prüfung greift jetzt auf allen interaktiven Anmeldewegen.
• Die Kundenregistrierung über WooCommerce konnte in bestimmten Konstellationen ohne Sicherheitsabfrage erfolgen. Der Prüfpfad erkennt den Kontext jetzt zuverlässig und lässt programmatische Registrierungen unberührt.
• Die Captcha-Engine verlangt eine gültige Signatur, bevor sie überhaupt etwas ableitet, und lehnt ab, wenn kein Server-Geheimnis vorhanden ist. Die Rechenparameter eines eingereichten Nachweises unterliegen jetzt serverseitigen Obergrenzen (je Parameter per Filter anpassbar), damit ein Nachweis keine unbegrenzte Rechenzeit auf dem Server auslösen kann.
• Der Einmal-Verbrauch eines gelösten Nachweises ist jetzt atomar und datenbankgestützt statt zweistufig und cache-abhängig; parallele Einreichungen desselben Nachweises können sich nicht mehr überholen. Die Lebensdauer der Verbrauchsmarke hängt an der signierten Challenge statt an der aktuellen Einstellung.
• Die Bild-Code-Challenge stellt über ihre Prüfroute keine neuen Nachweise mehr aus, bindet den bestandenen Bildcode an genau die Challenge, zu der er gehört, und begrenzt die Fehlversuche je Code.
• Im Under-Attack-Modus ist das Zugangs-Cookie an den Besucher gebunden statt frei übertragbar, und das Ticket, mit dem die Zwischenseite ihre eigene Abfrage ausstellt, ist einmalig, kurzlebig und ausschließlich für diesen Zweck gültig — an einem geschützten Formular wird es nicht mehr akzeptiert. Die Zwischenseite sendet ihr Formular außerdem wieder zuverlässig an die eigene Website.
• Die Auswertung der Proxy-Header wurde korrigiert; eine gespeicherte Cloudflare-Adressliste wird beim Lesen validiert und bei unplausiblem Inhalt zugunsten des mitgelieferten Standes verworfen. Beides verhindert, dass die Client-Adresse aller Besucher auf eine einzige Adresse zusammenfällt oder von außen bestimmbar wird.
• Die Prüfung gespeicherter Einstellungen unterscheidet jetzt, ob sie aus dem Backend-Formular oder aus einem programmatischen Schreibvorgang kommt. Damit können Import und Kommandozeile keine Werte mehr still verlieren, ohne dass die Prüfung ihre Schutzwirkung an anderer Stelle einbüßt.
• Der Updater akzeptiert nur noch geprüfte Bytes: Prüfsummenpflicht, nur HTTPS-Paket-URLs, Manifest-Prüfung gegen ein festes Schema, Größengrenze und ein kurzer Negativ-Cache bei nicht erreichbarem Manifest. Ein fremdes Plugin mit ähnlichem Paketnamen wird nicht mehr fälschlich blockiert, und zwei Konstellationen, die im Update-Dialog zu einem PHP-Fehler geführt haben, sind behoben.
• Die Release- und CI-Pipeline wurde gehärtet: Die Testsuiten laufen jetzt vollständig statt sich still zu überspringen, mehrere Prüfschritte melden Fehler statt sie zu verschlucken, externe Build-Bestandteile sind an Prüfsummen und Herkunft gebunden, und das Doku-Stylesheet kommt aus dem Repository statt von einem CDN.
• Bei den Daten: Die Aufbewahrungsfrist wird jetzt tatsächlich durchgesetzt, die Schema-Prüfung ist an eine Berechtigung gebunden, das Ereignis-Log speichert in mehreren Ereignistypen keine Verifizierungsdaten mehr, und die Deinstallation räumt netzwerkweit auf.
• Der Markup-Scanner der E-Mail-Obfuskation wurde ersetzt. Er unterscheidet Text, Tag, Kommentar und Rohtext-Bereiche jetzt nach denselben Regeln wie ein HTML-Parser; mehrere Konstellationen, in denen die Verschleierung Skript-Inhalte verändert oder ab einer bestimmten Stelle ganz ausgesetzt hat, sind damit erledigt.

Verbesserungen und Korrekturen:

• Diagnose: wp creacaptcha doctor hat zwölf neue Prüfungen — Abdeckung der Anmeldeformulare, WooCommerce-Checkout-Typ und Lost-Password-Kopplung, Ausschlussmuster und Inject-Pfade des Pfad-Schutzes, Schriftart der Bild-Code-Challenge, IP-Schreibweise des Servers und der Listen, Under-Attack-Erfolgsquote, Proxy-Header-Auswahl, Zusammenspiel der Zwischenseite mit einem Full-Page-Cache und gefährliche Bestandskonfiguration. Sieben bestehende Prüfungen haben etwas anderes geprüft, als sie ausgegeben haben; das ist korrigiert, ebenso die Zuordnung von Warnung und Fehler.
• Kommandozeile: aussagekräftige Ablehnungsgründe und korrekte Exit-Codes bei allen Listen-Befehlen, log list --fields= prüft gegen die tatsächliche Spaltenliste (auch bei leerem Ergebnis), log list --number= meldet die Deckelung, settings import benennt die Herkunft der Datei, settings load-defaults meldet verworfene Listeneinträge, settings export warnt bei sensiblen Inhalten und bei einem Zielpfad innerhalb der WordPress-Installation, test-bypass --cookie= verarbeitet mehrere Cookies und prozentkodierte Werte wie eine echte Anfrage.
• Statistik: Der CSV-Export ist gegen einen Wechsel des Datenbestands während des Schreibens abgesichert, der Schutz vor Formel-Injektion in Tabellenkalkulationen wurde erweitert, und der protokollierte Pfad entspricht jetzt dem tatsächlich gerouteten.
• Einstellungen: Warnungen der Eingabeprüfung werden im Backend jetzt angezeigt, gesperrte Felder tragen einen Erklärtext, vor dem Import steht ein Warnhinweis, und mehrere Hilfetexte benennen die tatsächlichen Fallen der jeweiligen Einstellung. Die pauschale Zusage „DSGVO-konform” am Schalter für die IP-Anonymisierung ist entfallen — sie sagte mehr, als der Schalter leistet.
• Dokumentation: Die Hook-Übersicht in dieser Datei war unvollständig; sie ist jetzt vollständig abgeglichen. Der Hook creationell_captcha_deactivated bekommt einen Parameter (bool $network_deactivating) — bestehende Handler sind davon nicht betroffen.

Neue Filter:

• creationell_captcha_max_derive_cost — Obergrenze der akzeptierten PBKDF2-Iterationen einer eingehenden Payload
• creationell_captcha_max_derive_time_cost — Obergrenze der akzeptierten Argon2id-Zeitkosten
• creationell_captcha_max_derive_memory_cost — Obergrenze der akzeptierten Argon2id-Speicherkosten
• creationell_captcha_max_derive_key_length — Obergrenze der akzeptierten Schlüssellänge
• creationell_captcha_max_solution_counter — Obergrenze des akzeptierten Lösungs-Counters
• creationell_captcha_code_max_attempts — Fehlversuche je Bild-Code, bevor der Code verbraucht wird
• creationell_captcha_underattack_pass_binding — Besucher-Fingerprint für die Bindung des Under-Attack-Zugangs-Cookies (leerer Rückgabewert schaltet die Bindung ab)
• creationell_captcha_export_max_rows — Obergrenze der Zeilen je CSV-Export des Ereignis-Logs
• creationell_captcha_email_buffer_max_bytes — Obergrenze der Antwortgröße, die der E-Mail-Obfuskator im Ganzseiten-Puffer-Modus verarbeitet

1.0.2

• Fix: Die WPForms-Integration registrierte creationell_captcha_wpforms_inject() am Hook wpforms_display_submit_before mit zwei Pflicht-Argumenten, während der Hook nur $form_data übergibt. Das löste beim Rendern jeder Seite mit einem WPForms-Formular einen Fatal Error („Too few arguments”) aus und brach die Seitenausgabe ab. Der zweite, ohnehin ungenutzte Parameter ist jetzt optional ($form = null) und accepted_args auf 1 korrigiert.

1.0.1

• Fix: Contributor-Einträge im Plugin-Detail-Popup erhalten jetzt einen display_name — zuvor loggte WordPress-Core eine PHP-Warning und zeigte die Contributor-Namen nicht an. Das Update-Manifest liefert das Feld nun mit; der Updater ergänzt es als Fallback auch für ältere Manifeste.
• Fix: Der no_update-Eintrag des Updaters enthält jetzt new_version, package, tested und requires_php — zuvor loggte WP-CLI bei wp plugin list eine PHP-Warning, wenn das Plugin aktuell war.
• Entfernt: Der seit v0.19.0 veraltete WP-CLI-Alias wp creacaptcha refresh-cloudflare-ips. Bitte wp creacaptcha cloudflare refresh verwenden.
• Verbessert: Die Plugin-Banner werden jetzt verlustfrei als AVIF kodiert.

1.0.0

Erstes stabiles Release. CreaCaptcha ist ein vollständig selbst-gehosteter Spamschutz für WordPress — ohne externe Dienste, ohne Tracking, ohne Lizenz-Gate.

Funktionsumfang:

• Proof-of-Work-Captcha (ALTCHA-kompatibel, PBKDF2/Argon2id) für Kommentare, Login, Registrierung und Passwort-Reset
• Formular-Integrationen: Contact Form 7, Forminator, WPForms, WooCommerce (Checkout, Login, Registrierung, Lost-Password)
• Generischer Interceptor für beliebige URL-Pfade und WordPress-Actions
• Firewall (IP-/CIDR-/User-Agent-Listen), per-IP-Rate-Limiter, Proxy-Support inkl. Cloudflare
• Under-Attack-Modus mit anpassbarer 503-Interstitial-Seite (Texte, Farben, Logo, Custom-CSS)
• Bild-Code-Challenge als optionale zweite Captcha-Stufe
• E-Mail-Obfuskation (Content-Filter oder Ganzseiten-Buffer)
• Statistik-Dashboard, Event-Log mit Suche/Filter/CSV-Export
• Umfassende WP-CLI-Integration (wp creacaptcha …)
• Widget-Anpassung (Themes, Farben, Custom-CSS, 20 Sprachen)

Neu in diesem Release:

• Plugin-Banner für den WordPress-Update-Screen
• Dokumentations-Sektion in der README (Web-Doku, Update-Manifest, API-Referenz)
• Contributors-Angabe im Update-Manifest erweitert

Das Update von v0.30.x erfolgt ohne Datenbank-Migration und ohne Breaking Changes — bestehende Einstellungen, Listen und Statistiken bleiben unverändert erhalten.

0.30.1

Wartungsrelease: Release-Infrastruktur umgestellt — keine funktionalen Änderungen am Plugin.

• Die Plugin-Releases werden ab dieser Version aus dem dedizierten, öffentlichen Release-Repository github.com/creationell-dev/creationell-captcha veröffentlicht. Download-, Update- und Dokumentations-URLs bleiben unverändert.
• Build-Pipeline gehärtet: GitHub-Actions und phpDocumentor auf feste Versionen gepinnt, Build-Staging vom Paketinhalt ausgeschlossen.

0.30.0

Under-Attack Pass-Event & Statistik-Übersicht — das Backend unterscheidet jetzt, ob ein Besucher die Under-Attack-Prüfung bestanden hat oder hängen blieb, und die Statistik-Übersicht erklärt ihre Zahlen selbst.

• Neuer Event-Typ underattack_passed: feuert, wenn ein Besucher die Under-Attack-PoW-Prüfung löst und das Pass-Cookie ausgestellt wird. Erscheint in Übersicht, Verlauf, Ereignis-Filter, CSV-Export und WP-CLI (wp creacaptcha stats, log list --type=underattack_passed).
• Neues Log-Gate „Bestandene Under-Attack-Prüfungen loggen” (Default: an); Aggregat-Zähler laufen unabhängig davon.
• Statistik-Übersicht: vier KPI-Kacheln statt drei — „Abgewehrt (24 h)” zählt nur noch echte Blocks (Firewall + Rate-Limit), Under-Attack hat eine eigene Kachel „Abfragen / bestanden”.
• Statistik-Übersicht: die flache Ereignis-Tabelle ist in vier thematische Gruppen mit Erklärungstext gegliedert (Formular-Captchas / Abgewehrte Zugriffe / Under-Attack-Modus / Technisch); nicht zugeordnete Typen landen automatisch in einer Auffanggruppe „Weitere Ereignisse”.
• Keine DB-Migration nötig; bestehende Events und Zähler bleiben unverändert gültig.

0.29.0

Logo im Under-Attack-Interstitial — die 503-Seite kann jetzt ein Logo oberhalb der Überschrift anzeigen.

• Neues optionales Feld „Logo-URL” in der Under-Attack-Section „Erscheinungsbild”. Leer = kein Logo (Default); bestehende Sites sehen ohne Aktion keine Änderung.
• UnderAttack::serve_interstitial() reicht die URL als $logo_url ans Template; das Template rendert ein zentriertes <img class="crea-ua-logo"> vor dem <h1>, gedeckelt auf max-height: 128px. Alt-Text = Website-Name (get_bloginfo('name')).
• Sanitization via esc_url_raw() beim Speichern entschärft gefährliche Schemata (javascript: o. Ä.); Ausgabe zusätzlich mit esc_url().
• Größe per .crea-ua-logo über das vorhandene „Eigenes CSS”-Feld überschreibbar. Setzbar über wp creacaptcha settings set underattack_logo_url <url>.

0.28.0

Feature-Modul 21 — Under-Attack-Customization: Wording und Erscheinungsbild der Interstitial-Seite sind ab sofort über das Backend konfigurierbar, ohne Plugin-Code zu patchen.

• Neue Section „Erscheinungsbild” im Under-Attack-Tab mit sieben optionalen Feldern: vier Texte (Browser-Tab-Titel, Überschrift, Hinweistext, NoScript-Hinweis), zwei Farben (Hintergrund, Textfarbe) und ein freies Custom-CSS-Feld.
• Renderer in UnderAttack::serve_interstitial() baut die drei Variablen $texts / $colors / $user_css und reicht sie ans Template weiter; leere Felder fallen auf die existierenden Hartcode-Defaults zurück.
• Template (includes/under-attack-interstitial.php) nutzt zwei neue CSS-Variablen --creationell-captcha-ua-bg und --creationell-captcha-ua-text für die Farben. Ein zweiter <style>-Block direkt nach dem Default-Stylesheet nimmt das Custom-CSS auf — alle Regeln des Defaults sind dort überschreibbar.
• Sanitization analog zu widget_custom_css: wp_strip_all_tags() neutralisiert </style><script>-Injection bevor der Wert die Template-Ausgabe erreicht.
• Alle sieben Felder sind über das bestehende wp creacaptcha settings set <key> <value>-CLI setzbar — neue Field-Typen waren nicht nötig, alle Typen (text, color, textblock) gibt es seit Modul 14.

Sites nach Update sehen ohne Aktion keine visuelle Veränderung — alle sieben Felder sind initial leer und das Template fällt damit auf die bisherigen Default-Werte zurück.

0.27.2

Metadaten-Anpassung an WordPress 7.0 / 6.9.

• Plugin-Header & README: Requires at least von 6.8 auf 6.9 angehoben, Tested up to von 6.8 auf 7.0 nachgezogen. WordPress 7.0 ist seit kurzem produktiv; der Plugin-Test-Lauf der bisherigen Module 1–20 ist gegen 7.0 sauber.
• Konstante: CREATIONELL_CAPTCHA_MIN_WP von '6.8' auf '6.9' angehoben. Sites auf WordPress 6.8 oder älter erhalten beim Aktivieren jetzt die bestehende Hinweisleiste „Erfordert WordPress 6.9 oder neuer.” statt das Plugin zu laden.
• Inline-Kommentar im Plugin-Bootstrap (WordPress 6.8+ → WordPress 6.9+) und die interne Entwickler-Dokumentation konsistent nachgezogen.

Keine funktionalen Code-Änderungen.

0.27.1

CSS-Fix: Widget-Abstand zum darauffolgenden Element im Standard-Modus.

• assets/css/widget.css: Die Block-Flow-Abstandsregel auf <altcha-widget> ist von margin-block-end auf padding-block-end umgestellt und auf den display="standard"-Modus eingeschränkt. Hintergrund: das Widget ist auf den geschützten Formularen typischerweise das letzte Kind im <form> — der bisherige margin-block-end kollabierte deshalb mit der Bottom-Kante des Form-Elements (kein padding-bottom/border-bottom/eigene BFC), sodass visuell überhaupt kein Abstand zum nachfolgenden Inhalt blieb. Padding kollabiert nicht — der konfigurierbare Abstand (Default jetzt 1rem statt 1.5em) ist daher zuverlässig sichtbar. Der CSS-Variablenname (--creationell-captcha-widget-margin-block-end) bleibt aus Kompatibilitätsgründen gleich.
• Floating/Overlay/Bar/Invisible-Modi bekommen den Abstand nicht mehr spurious mitgegeben — ihre eigentliche Widget-Darstellung ist position-fixed bzw. display:none, ein Inline-Spacer wäre dort nur ein toter 1.5em-Gap.

0.27.0

Feature-Modul 20 — Widget-i18n: Die Sicherheitsabfrage erscheint endlich in der korrekten Sprache, ohne dass der Admin etwas konfigurieren muss.

• Neue 20 vendorierte ALTCHA-Locale-Dateien unter assets/js/altcha-i18n/ (DE, EN, FR-FR/CA, ES-ES/419, IT, NL, PT-PT/BR, PL, CS, SK, DA, SV, FI, NB, HU, RO, EL) — je ~3 KB, Page-Load lädt weiterhin nur eine Datei.
• Neuer Helper creationell_captcha_resolve_widget_locale() mit Lookup-Tabelle (48 WP-Locale-Strings, inkl. formal/informal- Varianten) auf 20 ALTCHA-Codes.
• creationell_captcha_build_widget_markup() enqueued die passende Locale-Datei lazy (analog zum Theme-CSS-Pattern) und setzt language="<code>" am <altcha-widget>. Locales ohne Mapping überspringen beide Schritte — das Widget nutzt dann seine eigene <html lang>/Browser-Detection.
• Zwei neue Filter creationell_captcha_widget_locale_map und creationell_captcha_widget_locale für Projekt-Overrides ohne Plugin-Patch.
• wp creacaptcha status zeigt eine neue Zeile „Widget-Sprache” mit dem effektiven ALTCHA-Code plus dem WP-Locale-Ursprung.
• widget_strings_override bleibt unverändert und greift weiterhin als Pro-Schlüssel-Override on top der Auto-Locale.

0.26.2

Bugfix-Release: schließt eine Verify-Regression aus v0.22.0 / Commit c322b96, die seit der Korrektur des configuration-JSON-Attributs das ALTCHA-Widget dazu brachte, bei jedem gelösten PoW die /code-verify-Route aufzurufen — und dort mit 400 invalid_request abgewiesen zu werden, weil im Plain-Mode (ohne Code-Challenge im /challenge-Response) das code-Feld im Body fehlt.

• includes/widget.php: verifyUrl wird im configuration-JSON nur noch dann emittiert, wenn das Master-Setting code_challenge_enabled aktiv ist. Im Standardfall (Code-Challenge aus) verifiziert das Widget wieder rein client-seitig, ohne den überflüssigen Server-Roundtrip.
• includes/code-challenge.php: /code-verify akzeptiert das code-Feld jetzt als optional. Plain-Mode ({ payload } ohne code) durchläuft Engine::verify_structural(), prüft die Original-Signatur über den gleichen Single-Use-Transient-Schlüssel wie Engine::verify() (verhindert, dass eine einzelne gelöste PoW in N frische Payloads multipliziert wird) und gibt eine frische signierte Payload zurück. Code-Challenge-Modus bleibt funktional unverändert.

Die ALTCHA-verifyUrl-Mechanik schaltet das Widget pauschal in den Server-Verify-Modus — auch ohne Code-Challenge im Response. Beide Fixes zusammen: saubere Standard-Konfiguration ohne Roundtrip und Defense-in-Depth, falls code_challenge_enabled aktiv ist aber kein Trigger greift.

0.26.1

UX-Polish-Release: schließt die drei nicht-essenziellen UX-Befunde aus dem Qualitäts-Audit (Modul 18) ab.

• Neue requires_select-Semantik im Settings-Schema: Felder können jetzt nicht nur an einen booleschen Vorbedingungs-Toggle gekoppelt werden (requires => 'foo_enabled'), sondern auch an einen konkreten Wert eines anderen Select-Feldes (requires_select => ['widget_display' => 'floating']). Render-Layer setzt disabled, Sanitizer-Cascade bewahrt den gespeicherten Wert. Anwendung: die drei Floating-Felder widget_floating_anchor/widget_floating_placement/ widget_floating_offset werden jetzt nur aktiv geschaltet, wenn der Widget-Anzeige-Modus auf „Schwebend” steht — in jedem anderen Modus bleiben sie ausgegraut.
• Tools-Page „Auf Werkseinstellungen zurücksetzen”: deutliche notice-warning-Box oberhalb der Karte mit Hinweis auf die Listen-Leerung und Verweis auf die ungefährliche „Standardwerte laden”-Karte.
• Wortwahl „Sicherheitsabfrage” (user-facing Help-Texte) vs. „Captcha” (technische/Admin-Kontexte wie Tab-Label, Section-Titel, Engine- Begriffe) bleibt bestehen — das Audit hat die aktuelle Trennung als akzeptabel eingestuft.

0.26.0

Performance-Release: drei aufgeschobene Optimierungen aus dem Qualitäts-Audit (Modul 18) — Settings-Memoize, Analytics-Bump-Memoize und ein Composite-Index auf der Events-Tabelle.

• creationell_captcha_get_settings() cacht das Ergebnis pro Request in einer statischen Variable. Bisher rief jede Modul-Komponente (Interceptor, Firewall, Rate-Limiter, Under-Attack, jede Form- Integration) die Funktion mehrfach pro Request, jedes Mal mit array_merge über ~70 Default-Keys. Invalidierung läuft über die update_option/add_option/delete_option-Hooks für creationell_captcha_settings, sodass Caller direkt nach einem Speichervorgang den frischen Wert sehen.
• Analytics::record() sammelt die Daily- und Hourly-Counter-Deltas in request-lokalen Static-Caches und flusht sie via add_action('shutdown', …) in genau einem get_option/update_option-Paar pro Counter-Tabelle. Vorher: zwei Roundtrips pro Event — eine /challenge-Route mit aktivem log_challenge-Toggle und nachgelagerter Verifikation kommt damit bei 4–6 Roundtrips an. Jetzt: maximal 2 Roundtrips, unabhängig von der Anzahl der Events. Die Cutoff-Pruning-Logik wandert in apply_deltas() und läuft jetzt einmal je Counter statt einmal je Event. Konkurrente Updates aus parallelen Requests bleiben erhalten (Flush liest frischen Stand und addiert nur die eigenen Deltas).
• Composite-Index event_type_created (event_type, created_at) auf der Events-Tabelle. Dashboard-Queries mit event_type-Filter (Statistik-Tab, CSV-Export, Detail-Modal-Source) erzwangen bisher einen Filesort über den per-day-gesliceten Range. Mit dem Composite-Index läuft die typgefilterte Range-Abfrage als reiner Index-Range-Scan. Migration via Analytics::ensure_table() — dbDelta für Frischinstalls, SHOW INDEX-Guard plus ALTER TABLE als Fallback für bestehende Tabellen (dbDelta ist für Index-Adds historisch unzuverlässig). %i-Identifier-Platzhalter konsistent mit clear_events().

0.25.0

Qualitäts-Audit-Release: Security-Härtung des Updaters, Event-Log-Privacy, Body-Fingerprint-Maskierung sowie umfassende UX-Hilfetexte und Konsistenz- Fixes im Backend.

Sicherheit: - Updater (includes/class-plugin-updater.php): Checksum-Vergleich nutzt jetzt hash_equals() (timing-safe). Slug-Heuristik in verify_download_checksum() durch Exakt-Match gegen manifest.download_url ergänzt — verhindert Bypass über ein manipuliertes Manifest mit Slug-freier Download-URL. Manifest-Fetch über wp_safe_remote_get() (Defense-in-Depth gegen SSRF). - Event-Log: Analytics::current_path() reduziert REQUEST_URI auf den Pfad-Anteil. GET-Token, Magic-Login-Links und API-Keys landen damit nicht mehr im persistenten Event-Log. - Request-Body-Fingerprint: Feldnamen mit sensitiven Substrings (password, secret, token, iban, api_key, cvv, …) werden vor dem JSON-Encode durch [masked:<sha256-8>] ersetzt, um Custom-Form- Schemata nicht im Event-Log preiszugeben. Neuer Filter creationell_captcha_request_body_sensitive_patterns für projektspezifische Erweiterungen. - Analytics::clear_events() nutzt jetzt wpdb::prepare( 'DELETE FROM %i', $table ) statt Roh-Interpolation (WP-6.2+-konform).

Backend-UX: - DSGVO-First: Default analytics_anonymize_ip von false auf true. Neue Installs anonymisieren IPs out-of-the-box; bestehende Installs behalten ihre Wahl. - Rate-Limit-Default ratelimit_max von 10 auf 30 (besser für Login-Scope — ein Nutzer mit Tippfehler-Marathon läuft nicht mehr ins 5-Minuten-Lockout). - Tab-Reihenfolge: „Analytics” steht nun vor „E-Mail-Schutz” (näher an den Schutzmodulen). - Firewall-Tab: Sektionen sortiert auf Proxy → Firewall → Bypass → Rate-Limit (Bypass folgt der Firewall, deren Regeln sie überstimmt). - widget_code_challenge_display in die Code-Challenge-Section verschoben und an code_challenge_enabled gekoppelt. - 21 fehlende oder schwache Settings-Hilfetexte ergänzt (algorithm, difficulty, challenge_expiry, alle widget_*-Customization-Felder, Core-Forms-Toggles, alle Form-Plugin-Toggles, Rate-Limit-Felder, firewall_proxy_header, firewall_ip_block/ua_block, underattack_enabled, analytics_event_log, bypass_cookies, firewall_cloudflare_auto_refresh, interceptor_skip_logged_in). Section-Renderer für Engine, Code-Challenge und Firewall mit erklärenden Texten ergänzt (PoW-Konzept, OR-Logik der Trigger, CIDR-Notation). - interceptor_actions-Hilfetext nennt jetzt die edit_posts-Exemption (Autoren/Editoren weiterhin ausgenommen). - Tools-Page: Reset-Karte + Confirm-Dialog erwähnen jetzt explizit auch Interceptor- und Bypass-Listen.

WP-CLI: - wp creacaptcha status zeigt drei neue Zeilen: Proxy-Modus, CF-Trust / CF-Auto-Refresh und IP-Anonymisierung. - wp creacaptcha doctor prüft ext-sodium, wenn der Algorithmus auf Argon2id steht — Error mit Fix-Vorschlag, wenn die Extension fehlt.

Code-Qualität: - defined( constant_name: 'ABSPATH' ) → defined( 'ABSPATH' ) in 48 Dateien. Named-Args auf PHP-Builtins sind nicht stabilitäts-garantiert und werden von Static-Analyzern als Anti-Pattern geflaggt. - PHPDoc: über 20 eigene do_action/apply_filters-Hooks vollständig dokumentiert (creationell_captcha_event, Interceptor-Filter-Familie, WPForms-/WC-Autoinject-Filter), Repeat-Dispatches mit WordPress-Core- style „This action is documented in …“-Verweisen. - REST-Callback-PHPDocs in includes/rest.php und includes/code-challenge.php ergänzt (@param/@return mit Status-Code-Tabelle).

Tooling & Doku: - phpdoc.xml Version-Drift 0.1.0 → 0.25.0. - Plugin-Header-Description nennt jetzt Firewall, Rate-Limit, Under-Attack, E-Mail-Obfuskation und Code-Challenge (vorher: nur PoW-Spamschutz). - README-Description um WPForms-, WooCommerce-Integrationen und Code-Challenge-Absatz erweitert. - uninstall.php: Transient-Cleanup vom _used_-Prefix auf das gesamte creationell_captcha_-Prefix erweitert; entfernt jetzt auch _cc_*, _rl_* und _git_update_*-Caches/Locks.

Behebt: - Inkorrekt formulierter IPv6-Anonymisierungs-Hilfetext (includes/settings.php): stimmt jetzt mit der Code-Logik überein (erste 48 Bit bleiben, letzte 80 Bit auf 0). - Tippfehler „mehrmietigen” → „mehrmandantigen (Shared Hosting)“. - Tested up to: 6.9 → 6.8 (WordPress 6.9 ist Stand 2026-05-28 noch nicht released).

0.24.0

• WP-CLI-Nachzug Phase 2: schließt sieben CLI-Coverage-Lücken nach den Modulen 14–16.
• Neuer Listen-Befehl wp creacaptcha watchlist add|remove|list|clear für die Code-Challenge-Watchlist (code_challenge_watchlist).
• wp creacaptcha status zeigt sechs zusätzliche Zeilen: Form-Plugin- Toggles (CF7, Forminator, WPForms, WooCommerce + gruppierte Zeile für die vier Woo-Sub-Toggles) und den Watchlist-Eintragszähler.
• wp creacaptcha enable code-challenge / disable code-challenge togglet code_challenge_enabled über feature_map(). Doc-Strings von enable/disable listen jetzt alle 19 Features (vorher 12, fehlten WPForms, WooCommerce und die vier wc-* Mappings).
• wp creacaptcha settings set unterstützt jetzt zusätzlich die Feldtypen text, color und textblock — damit werden die Widget-Customization-Felder (widget_floating_anchor, widget_primary_color, widget_custom_css, widget_strings_override) über die CLI setzbar. Verworfene JSON-/Hex-Werte werden via WP_CLI::warning() gemeldet.
• wp creacaptcha doctor ergänzt einen GD-Extension-Check: wenn code_challenge_enabled aktiv ist, muss die PHP-GD-Extension geladen sein (sonst error mit Exit-Code 1).
• wp creacaptcha log list unterstützt jetzt --fields= (WP-CLI- Standard); Default-Output bleibt die bisherige 4-Spalten-Übersicht, verfügbar werden alle 15 Spalten der Event-Log-Tabelle.
• Neuer Befehl wp creacaptcha log show <id> zeigt einen einzelnen Event mit allen 15 Spalten als Key-Value-Tabelle (oder JSON/YAML/CSV via --format).

0.23.0

• WPForms-Integration: Neues Setting „WPForms schützen” im Formulare-Tab. Aktiv, sobald das WPForms-Plugin installiert ist. Auto-Inject des Widgets vor dem Submit-Button (wpforms_display_submit_before); Verify über wpforms_process-Action, Fehlerausgabe via wpforms()->process->errors[$form_id]['header'].
• WooCommerce-Integration: Master-Toggle „WooCommerce schützen” plus vier Sub-Toggles für Checkout, My-Account-Login, My-Account-Registrierung und Lost-Password. Auto-Inject auf den nativen Woo-Hooks (woocommerce_review_order_before_submit, woocommerce_login_form_end, woocommerce_register_form, woocommerce_lostpassword_form); Verify auf woocommerce_after_checkout_validation, woocommerce_process_login_errors, woocommerce_registration_errors.
• Lost-Password ist Render-only: Server-Verifikation läuft über protect_password_reset (WordPress-Kernformular), weil Woo-Lost-Password über WP-Core retrieve_password() zurückläuft und damit lostpassword_post feuert.
• Produkt-Bewertungen werden bewusst nicht über einen eigenen Sub-Toggle abgebildet — Reviews sind WordPress-Kommentare und durch protect_comments abgedeckt; der Hilfetext am Master-Toggle weist darauf hin.
• Render-Override-Filter (alle fünf, einheitliche (bool, int $form_id)- Signatur): creationell_captcha_wpforms_autoinject, creationell_captcha_wc_checkout_autoinject, creationell_captcha_wc_login_autoinject, creationell_captcha_wc_registration_autoinject, creationell_captcha_wc_lost_password_autoinject. Bei false wird das Auto-Inject übersprungen; die Verifikation bleibt aktiv.
• WP-CLI: sechs neue Feature-Schlüssel für wp creacaptcha enable|disable — wpforms, woocommerce, wc-checkout, wc-login, wc-registration und wc-lost-password.
• Bypass-Kette und Kill-Switch wirken wie bei den bestehenden Integrationen: jeder Verify-Pfad ruft creationell_captcha_request_bypassed() und respektiert CREATIONELL_CAPTCHA_DISABLE.

0.22.0

• Widget-Bugfix: Der ALTCHA-<altcha-widget>-Custom-Element-Tag erkennt nur 9 spezifische HTML-Attribute (auto, challenge, configuration, display, language, name, theme, type, workers) — alle anderen Props (Verify-URL, Floating-Anchor/Placement/Offset, Code-Challenge- Display, Hide-Footer/Logo, Strings-Override) müssen als JSON-Blob über das configuration-Attribut übergeben werden. Bisher hat das Plugin diese Settings als Einzelattribute emittiert, die das Widget stillschweigend ignoriert hat. Sichtbare Folgen: Floating-Anchor griff nicht, ALTCHA-Footer/Logo blieben sichtbar, Code-Challenge-Modal-Modi (overlay/bottomsheet) wurden ignoriert, eigene Übersetzungen waren wirkungslos. Mit v0.22.0 wirken alle Modul-14-Settings korrekt — das ist eine Verhaltensänderung, falls jemand diese Felder auf Nicht- Default gesetzt hatte.
• Bild-Code-Challenge: Zweite Captcha-Stufe nach der Proof-of-Work-Verifikation — ein vom Server ausgestelltes PNG mit einem 4–8-stelligen Code, den der User abtippen muss. Self-hosted, kein externer Dienst, kein ALTCHA Sentinel.
• Neue Section „Bild-Code-Challenge” im Captcha-Tab mit Master-Toggle und drei unabhängigen Trigger-Bedingungen: Under-Attack-Modus, Rate-Limit- Schwellwert (konfigurierbar 50–95 %) sowie eine eigene Watch-Liste von IPs/CIDRs. Mehrere Trigger gleichzeitig sind OR-verknüpft.
• Code-Optionen: Länge 4–8, Zeichensatz (nur Ziffern / alphanumerisch / alphanumerisch ohne Verwechsler), Token-Gültigkeit 60–900 Sekunden.
• Zwei neue REST-Endpoints: GET /wp-json/creationell-captcha/v1/code-image (PNG-Bild) und POST /wp-json/creationell-captcha/v1/code-verify (Code-Prüfung, liefert eine serverseitig gelöste ALTCHA-Payload, die durch den bestehenden Verifizierungspfad geht). Tokens sind opake Server- Identifier (32 Hex), Code lebt nur in einem WP-Transient — kein Client-side-Leak des erwarteten Codes.
• Trigger „Immer”: Vierter Trigger-Toggle in der Code-Challenge-Section, damit die Code-Challenge unabhängig von Under-Attack / Rate-Limit- Schwelle / Watch-Liste bei jedem Captcha-Request ausgespielt wird — sinnvoll fürs lokale Testen oder pauschal erhöhte Sicherheit. Default aus.
• Under-Attack-Schutz: Code-Challenge wird auf dem Under-Attack-Inter- stitial unterdrückt (das Interstitial-Widget ist invisible — ein Code- Modal könnte nicht angezeigt werden). Das Interstitial hängt einen HMAC-signierten Kontext-Token an die challenge-URL, der nur server- seitig signierbar ist; ein Angreifer kann die Suppression nicht selbst triggern.
• Das <altcha-widget> bekommt verifyUrl (sowie alle anderen Modul-14- Settings) via das configuration-JSON-Attribut, damit es vom Widget überhaupt gelesen wird.
• Bild-Rendering via PHP-GD mit vendorierter DejaVuSans-Bold-TTF unter assets/fonts/captcha.ttf und naiver Anti-OCR-Verzerrung (rotierte Zeichen, Querlinien, Rauschen). Wenn die TTF-Datei fehlt, fällt der Renderer auf den GD-Bitmap-Font 5 zurück.
• WP-CLI: wp creacaptcha status zeigt eine neue Zeile „Code-Challenge” mit dem effektiven Zustand (an / aus / inaktiv (kein GD)).
• Bypass-Schutz: Engine::verify() lehnt jeden Payload ab, in dem parameters.data.ccode gesetzt ist — verhindert, dass ein Angreifer den ursprünglichen Code-Challenge-Payload direkt am Form-Submit vorbei einreicht. Frische Payloads aus Engine::issue_signed_payload() haben kein data.ccode und passieren den Filter.
• Wenn die PHP-GD-Extension fehlt, deaktiviert sich das Feature stillschweigend, der bestehende PoW-Flow bleibt unangetastet, und in der Settings-Section erscheint eine Warn-Notice.

0.21.0

• Widget: Vendoriert jetzt das ALTCHA-Basis-Stylesheet (dist/external/altcha.css) und die sieben Theme-CSS-Files (dist/themes/*.min.css). Ohne diese fehlten alle Display-Modus-Positionierungen (floating/overlay/bar) komplett, und das Theme-Attribut hatte keinen sichtbaren Effekt.
• Widget: widget_display-Option bottomsheet entfernt — der Wert war kein gültiger ALTCHA-display-Modus (nur Inline-Fallback auf standard). Stattdessen neues Setting widget_code_challenge_display (standard/overlay/bottomsheet) für die ALTCHA-Code-Challenge-Modal, wo bottomsheet tatsächlich hingehört.
• Widget: Drei neue Settings für den schwebenden Modus: widget_floating_anchor (CSS-Selektor, leer = erster Submit-Button), widget_floating_placement (auto/top/bottom), widget_floating_offset (px, 0-200). Ohne Anchor bleibt das schwebende Widget off-screen — Help-Text macht das jetzt klar.
• Update-Procedure für das Widget-Asset auf einen abgesicherten npm-Bezug umgestellt (Schutz vor kompromittierten npm-Paketen).
• Architektur: Neuer Field-Type text (single-line input) für CSS-Selektor- und ähnliche String-Settings.

0.20.0

• Widget: Acht neue Customization-Settings unter „Captcha → Widget-Erscheinungsbild”. Display-Modus (standard, floating, overlay, bar, invisible, bottomsheet), Interaktions-Typ (checkbox/switch/native), automatische Auslösung (none/onload/onsubmit), eines der acht ALTCHA-v3-Themes, optionales Ausblenden des ALTCHA-Brandings, Akzentfarbe per Color-Picker, eigenes CSS und JSON-Override für die Widget-Texte.
• Widget: Das alte zusammengesetzte widget_mode-Setting (visible/auto/overlay) entfällt; ein Upgrade-Hook migriert beim ersten Admin-Aufruf automatisch auf die neuen Keys (visible → standard+none, auto → invisible+onload, overlay → floating+onsubmit).
• Widget: Der overlay-Modus aus Modul 11a wird jetzt korrekt mit der v3- Syntax display="floating" ausgespielt (vorher veraltetes floating="auto").
• Widget: Inline-CSS-Variable --creationell-captcha-primary überschreibt die ALTCHA-Standard-Akzentfarbe, wenn widget_primary_color gesetzt ist. Eigenes CSS wird direkt danach ausgegeben und kann beliebig überschreiben.
• WP-CLI: wp creacaptcha status zeigt eine neue Zeile „Widget-Anzeige” mit dem aktiven Display-Modus.
• Architektur: Zwei neue Field-Typen color und textblock ergänzen das Settings-Framework. textblock speichert mehrzeiligen Text ohne die Line-Listen-Semantik des bisherigen textarea-Typs.

0.19.0

• WP-CLI: Fünf neue Listen-Subbefehle für die seit v0.13.0 hinzugekommenen Listen-Settings — wp creacaptcha trusted-proxies|bypass-ua|bypass-cookies|actions|inject-paths, jeweils mit add|remove|list|clear. Damit sind alle Listen über dedizierte Befehle pflegbar, ohne den Umweg über settings set.
• WP-CLI: Neue Subcommand-Gruppe wp creacaptcha cloudflare mit refresh/clear/status. Der alte Top-Level-Befehl wp creacaptcha refresh-cloudflare-ips bleibt als Deprecation-Alias erhalten (Entfernung frühestens v1.0.0).
• WP-CLI: Neuer Diagnose-Befehl wp creacaptcha test-bypass, simuliert die Bypass-Auswertung mit --ip/--ua/--cookie-Flags. Exit 0 bei Bypass, Exit 1 sonst.
• WP-CLI: Neuer Diagnose-Befehl wp creacaptcha doctor mit 9 Pflicht-Checks (Vendored Library, HMAC-Secrets, Event-Log-Tabelle, Cloudflare-Refresh-Cron, Kill-Switch, Captcha-Plugin-Konflikte, PHP-Version, Cloudflare-Cache-Alter, Settings-Defaults). Erweiterbar über den Filter creationell_captcha_doctor_checks.
• WP-CLI: wp creacaptcha status listet jetzt auch die fünf neuen Listen mit Eintragszählern.
• Werkzeuge-Seite: Neuer fünfter Block „Cloudflare-IP-Cache” mit Status (gecachte v4/v6-Ranges, letzter Refresh, nächster Cron-Run, Quelle) und zwei Buttons („Jetzt aktualisieren”, „Cache leeren”). Beide Buttons rufen exakt die gleichen Helfer wie die CLI.
• Refactor: Die feldspezifische Validierung für Action-Patterns und Bypass-Cookies wurde aus creationell_captcha_sanitize_settings() in zwei wiederverwendbare Helfer extrahiert — Charset-Änderungen sind jetzt an einer Stelle gepflegt. Außerdem wurde request_bypassed() in eine reine evaluate_bypass(?ip, ?ua, cookies) plus dünnen Globals-Wrapper aufgeteilt; alle bestehenden Aufrufer bleiben unverändert.

0.18.0

• Interceptor: Drei neue Mechaniken. Die Pfad-Liste (Geschützte Pfade) unterstützt jetzt !-Präfix für Ausschluss-Muster (Allow-Liste mit Ausnahmen), z. B. /forms/* zusammen mit !/forms/whitelisted. Eine neue Liste Geschützte Aktionen schützt WordPress-Action-Endpoints (das $_POST[action]- oder $_GET[action]-Feld auf admin-post.php / admin-ajax.php) — selbst wenn diese sonst durch den is_admin()-Bypass ausgenommen wären. Eine neue Liste Inject-Pfade injiziert die Sicherheitsabfrage automatisch vor jedem </form> der passenden Seiten — nützlich für Theme- oder Drittanbieter-Formulare, die sich nicht direkt modifizieren lassen (idempotent: Formulare mit bereits eingebautem Widget werden übersprungen).

0.17.0

• Logging-Granularität: Sechs neue Backend-Checkboxes (Erfolgreiche Verifikationen loggen, Fehlgeschlagene Verifikationen loggen, Firewall-Blocks loggen, Rate-Limit-Blocks loggen, Under-Attack-Abfragen loggen, Ausgestellte Challenges loggen) steuern, welche Ereignistypen in den Detail-Event-Log geschrieben werden. Aggregierte Tages- und Stundenzähler erfassen alle Typen unabhängig davon. Per-Default sind die ersten fünf an, Ausgestellte Challenges loggen ist aus (hochvolumig).
• Neuer Ereignistyp challenge — wird bei jedem REST-Aufruf der Challenge-Route gefeuert. Im Statistik-Dashboard erscheint die neue Kachel/Spalte „Challenges ausgestellt” automatisch.
• Request-Body-Fingerabdruck: Optionaler neuer Schalter Request-Body-Fingerabdruck speichern. Wenn aktiv, wird pro Event-Log-Zeile eine JSON-Map aus Feldnamen und Wertlängen mit abgelegt — ohne die Werte selbst. Hilft bei der Angriffsmuster-Analyse, ohne PII zu speichern.
• IP-Anonymisierung: Optionaler neuer Schalter IP-Adressen anonymisieren trunkiert IPv4-Adressen auf das letzte Oktett und IPv6 auf die letzten 80 Bit, bevor sie in den Event-Log geschrieben werden — DSGVO-konform.

0.16.0

• Bypass: Neue Backend-Sektion „Bypass” im Firewall-Tab mit drei Eintragsarten, die jeweils Firewall, Rate-Limiter, Captcha und Under-Attack-Modus gleichermaßen umgehen — die bisherige IP-Erlaubnisliste (jetzt global), eine User-Agent-Wildcard-Liste und eine Cookie-Bypass-Liste im Format „name=wert”. Bypass-Treffer auf Formular-Ebene erscheinen im Event-Log als verified-Eintrag mit passendem Grund (IP-Allowlist / UA-Bypass / Cookie-Bypass).
• Widget: Dritter Anzeigemodus „Schwebendes Overlay” — die Sicherheits- abfrage erscheint als kleines Pop-up über dem Submit-Button und löst beim Submit automatisch.

0.15.0

• Firewall/IP-Erkennung: Der weitergeleitete Header (X-Forwarded-For, X-Real-IP, CF-Connecting-IP, True-Client-IP) wird nur noch dann beachtet, wenn die direkte Verbindung aus einem vertrauenswürdigen Hop kommt. Neue Sektion „Proxy & IP-Ermittlung” im Firewall-Tab mit Textarea für vertrauenswürdige Proxies, Toggles für Private-Netze und Cloudflare und optionalem täglichem Cron-Refresh der CF-Ranges. Cloudflare-Snapshot wird mitgeliefert. Die Trust-Liste lässt sich zusätzlich über die wp-config-Konstante CREATIONELL_CAPTCHA_TRUSTED_PROXIES ergänzen. Bei aktivem Proxy-Modus ohne konfigurierte Trust-Quelle erscheint im Backend ein Hinweis. Neuer WP-CLI-Befehl wp creacaptcha refresh-cloudflare-ips.

0.14.0

• Statistik: Die Statistik-Seite hat einen „↻ Aktualisieren”-Button. Der „Ereignisse”-Tab erfasst je Ereignis zusätzlich Plugin/Integration, Aktion, Formular-ID, Auslöser-Grund, User-Agent, Referrer, Benutzer-ID und die eingereichten Verifizierungsdaten, zeigt eine erweiterte Spaltenauswahl und öffnet pro Zeile ein Detail-Fenster mit allen erfassten Feldern. Der CSV-Export enthält die neuen Felder.

0.13.0

• WP-CLI: neue Befehlsgruppe wp creacaptcha … für Status, Diagnose, Statistik, Einstellungen (lesen/setzen/exportieren/importieren/zurücksetzen), Modul-Aktivierung, Pflege der IP- und User-Agent-Listen, Verwaltung des Event-Logs und eine Reparatur-Routine.
• Backend: neue Seite CreaCaptcha → Werkzeuge zum Exportieren und Importieren der Einstellungen, für einen vollständigen Reset auf Werkseinstellungen sowie zum Laden der Standardwerte unter Beibehaltung der gepflegten Listen.

0.12.0

• Statistik: Der „Ereignisse”-Tab hat jetzt eine Filter-Leiste — Freitextsuche über IP-Adresse und Pfad, Filter nach Ereignistyp und ein Von/Bis-Datumsbereich —, blättert seitenweise durch alle aufgezeichneten Ereignisse und bietet einen CSV-Export der jeweils gefilterten Ereignismenge zur weiteren Analyse.

0.11.0

• Statistik: Die Statistik-Seite ist jetzt ein Dashboard mit drei Tabs (Übersicht, Verlauf, Ereignisse). Der „Übersicht”-Tab zeigt KPI-Kacheln für den 24-Stunden-Blick und eine Vergleichstabelle über vier Zeitfenster (24 Stunden, 7 Tage, 30 Tage, 90 Tage); ein neuer stündlicher Zähler liefert die Daten für das 24-Stunden-Fenster.

0.10.0

• Backend: Die Einstellungsseite ist jetzt in sechs thematische Tabs gegliedert (Captcha, Formulare, Firewall, Under-Attack, E-Mail-Schutz, Analytics) statt einer langen Liste — übersichtlicher, mit weiterhin einem gemeinsamen „Änderungen speichern” für alle Tabs.

0.9.0

• E-Mail-Schutz: zusätzlicher Ganzseiten-Buffer-Modus, der das gesamte Seiten-HTML verarbeitet und damit auch theme-hart-kodierte mailto:-Links und Adressen (z. B. in Footer-Templates) verschleiert; der Modus ist unter „Einstellungen → CreaCaptcha → E-Mail-Schutz” wählbar.

0.8.0

• E-Mail-Obfuskation: mailto:-Links und Klartext-E-Mail-Adressen in Inhalten, Auszügen, Text-Widgets und Kommentaren werden im Seitenquelltext verschleiert und per JavaScript erst im Browser wiederhergestellt; ohne JavaScript erscheint ein neutraler Platzhalter.

0.7.0

• Analytics & Event-Logging: datenschutzfreundliche aggregierte Tageszähler je Ereignistyp und ein Statistik-Dashboard; optional ein detaillierter Event-Log (eigene Tabelle, IP-Adressen) mit konfigurierbarer Aufbewahrung.

0.6.0

• Under-Attack-Modus: ein einschaltbarer Notfall-Modus, der jeden anonymen Besucher per Interstitial-Proof-of-Work-Abfrage prüft, bevor er die Website erreicht; ein zeitlich begrenzter, signierter Pass-Cookie lässt geprüfte Besucher danach frei surfen.

0.5.0

• Firewall & Rate-Limiting: IP-Blockliste/-Erlaubnisliste (inkl. CIDR-Bereiche), User-Agent-Blockliste und ein per-IP-Rate-Limiter mit wählbarem Wirkungsbereich. Beide laufen als frühe Request-Guards, mit Proxy-Modus für die Client-IP-Ermittlung.

0.4.0

• Integrationen für Contact Form 7 und Forminator: automatischer Proof-of-Work-Schutz für die Formulare beider Plugins, mit [creationell_captcha]-Platzhalter zur Positionierung und je einem Einstellungs-Schalter.

0.3.0

• Interceptor-Modul: generischer serverseitiger Request-Schutz für eigene Formular-Pfade (*-Wildcards, fail-closed), Shortcode [creationell_captcha] und Template-Tag creationell_captcha_widget() zum Einbau des Widgets in beliebige Formulare.

0.2.0

• Captcha-Mechanik: Proof-of-Work-Sicherheitsabfrage (PBKDF2/SHA-256 oder Argon2id), Challenge-REST-Endpoint, gebündelte ALTCHA-Widget-Web-Component, Replay-Schutz und Schutz der vier WordPress-Kernformulare.

0.1.0

• Erstes Grundgerüst: Plugin-Bootstrap, Settings-API-Seite, gebündelte ALTCHA-Bibliothek (Composer + Strauss) und Self-Hosted-GitHub-Updater.