Wer einen WooCommerce-Shop mit dem Plugin Registration Form for WooCommerce von ThemeGrill betreibt, sollte heute noch aktualisieren. In Versionen bis einschließlich 1.1.4 lässt sich beim Anlegen eines Kundenkontos im Checkout die eigene Rolle frei wählen – inklusive administrator. Ein Angreifer braucht dafür kein Konto und kein Vorwissen, nur eine Bestellung mit präpariertem Formularfeld. Das Advisory listet die Schwachstelle unter CVE-2026-119075 mit einem CVSS-Wert von 9,8. Der Hersteller hat am 6. November 2026 Version 1.1.5 veröffentlicht, die den Fehler behebt.

Was das Plugin macht und wo der Fehler sitzt

„Registration Form for WooCommerce" erweitert das Standard-Registrierungsformular des Shop-Systems um zusätzliche Felder – etwa Rechnungsadresse, Telefonnummer oder Zustimmung zur Datenschutzerklärung. Rund 1.000 aktive Installationen weist das offizielle Plugin-Verzeichnis für die kostenlose Version aus. Das Plugin bietet zwei Wege für die Registrierung: über die Seite Mein Konto und direkt beim Checkout, wenn im WooCommerce-Backend die Option „Kundenregistrierung an der Kasse erlauben" aktiv ist.

Genau an dieser zweiten Stelle hat das Plugin bis 1.1.4 einen fatalen Unterschied gemacht: Auf dem Mein-Konto-Weg prüfte der Code die übermittelte Nutzerrolle gegen eine Liste zulässiger Werte. Im Checkout-Pfad dagegen landete der rohe POST-Parameter user_roles ungeprüft in der Datenbank. Wer dem Formular beim Checkout user_roles=administrator mitgab, bekam ein Administrator-Konto zugewiesen – ohne Login, ohne Prüfung.

Stilisierter Online-Shop-Button als Symbolbild für WooCommerce-Checkout

Bild: Symbolbild – Online-shop button von Namakkalshowroom, Lizenz CC BY-SA 4.0, via Wikimedia Commons.

Auswirkung: Vollständige Shop-Übernahme

Ein Administrator in WordPress kann alles: Plugins installieren, Dateien hochladen, PHP-Code ausführen, andere Konten löschen oder stilllegen. Für einen Shop heißt das in der Praxis: Zahlungsflüsse umlenken, Bestelldaten abgreifen, einen persistenten Backdoor-Plugin-Loader einschleusen oder die Seite komplett defacen. Da die Lücke ohne jede Authentifizierung ausnutzbar ist und über ein öffentlich erreichbares Formular geht, lässt sie sich einfach automatisieren.

Das Plugin-Changelog nennt den Fehler knapp: „Prevented privilege escalation via the user role submitted at checkout." Es ist nicht das erste Mal, dass dieses Plugin eine Rechte-Eskalation einbaut – Version 1.1.3 hatte im August 2026 bereits eine ähnlich gelagerte Lücke geschlossen, damals über eine unvalidierte Formular-ID (Changelog: „Prevented privilege escalation via unvalidated registration form ID."). Dass der Checkout-Pfad bei der ersten Runde übersehen wurde, legt nahe, dass die Rollenprüfung an mehreren Stellen separat implementiert war.

Bin ich betroffen?

Betroffen ist jede WordPress-Installation, die das kostenlose Plugin registration-form-for-woocommerce in einer Version bis einschließlich 1.1.4 aktiv hat. Die Version findest du im Backend unter Plugins → Installierte Plugins oder per WP-CLI:

wp plugin get registration-form-for-woocommerce --field=version

Ob der Checkout-Pfad des Plugins überhaupt aktiv war, hängt an der WooCommerce-Einstellung WooCommerce → Einstellungen → Konten und Datenschutz → Erlaube Kunden, ein Konto beim Checkout zu erstellen. Steht der Haken, war der verwundbare Pfad erreichbar. Steht er nicht, konnte die Lücke zwar nicht über den Checkout ausgenutzt werden – ein Update bleibt trotzdem Pflicht, weil die Einstellung jederzeit umgelegt werden kann.

Was du jetzt tun solltest

Die Reihenfolge ist wichtig: erst patchen, dann aufräumen.

  1. Plugin auf 1.1.5 aktualisieren. Über das Admin-Backend oder per CLI:
    wp plugin update registration-form-for-woocommerce
  2. Alle Administrator-Konten prüfen. Lass dir die Liste ausgeben und gleiche sie mit den Konten ab, die du selbst angelegt hast:
    wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
    Alles, was nach der Freischaltung des Plugins angelegt wurde und du nicht kennst, ist ein Kandidat für sofortige Deaktivierung.
  3. Rollen auch bei Nicht-Admins prüfen. Der Angreifer muss sich nicht zwingend administrator setzen – auch editor oder shop_manager reichen für viel Schaden. Prüfe deshalb alle privilegierten Rollen.
  4. Webserver- und WooCommerce-Logs sichten. Suche in den Request-Logs nach POST-Requests auf die Checkout-URL mit einem Parameter user_roles im Body. Wenn dein Access-Log keine Bodies aufzeichnet, suche nach ungewöhnlichen User-Registrierungen zur gleichen Uhrzeit wie bezahlte oder abgebrochene Bestellungen.
  5. Bei bestätigter Kompromittierung: Fremde Admin-Accounts entfernen, Passwörter aller verbliebenen Admin-Konten zurücksetzen, aktive Logins invalidieren (neues AUTH_KEY/SECURE_AUTH_KEY in der wp-config.php), alle Plugins auf unerwartete Dateiänderungen oder neu hinzugekommene PHP-Dateien im wp-content-Verzeichnis prüfen. Ein wp core verify-checksums vergleicht die Kerndateien mit dem offiziellen Hash-Satz.

Wenn du den Shop professionell betreibst und das Sicherheitsereignis belastbar bewerten musst, lohnt sich zusätzlich ein Blick in die Datenbank-Tabelle wp_usermeta. Dort stehen die tatsächlichen Rollen-Zuweisungen pro Nutzer – manipulative Änderungen am laufenden Konto zeigen sich dort zuverlässiger als in der Admin-Oberfläche, die unter Umständen gefiltert wird.

Einordnung

Die Lücke reiht sich ein in eine bekannte Fehlerklasse: Plugins, die serverseitig keine Rollen-Whitelist durchsetzen, sondern dem Browser glauben, welchen Account er gern hätte. Dass das Fehlermuster in denselben Plugin schon einmal auftauchte, zeigt den Wert automatisierter Security-Prüfungen im Build-Prozess – ein statischer Blick auf jede Stelle, an der wp_update_user, wp_insert_user oder $user->set_role() mit Eingabedaten aus Request-Parametern aufgerufen wird, hätte den zweiten Treffer vermutlich vermieden.

Shop-Betreiber, die Plugins für den Checkout-Pfad einsetzen, sollten generell prüfen, ob Rollen- und Rechte-Felder im Frontend überhaupt editierbar sind – und falls ja, warum. In einem öffentlichen Registrierungsformular hat ein Feld user_roles nichts verloren.

Quellen

Bildnachweis